Doubt about bean discovery default behaviour
by Michel Graciano
Hi all,
I have been reading the CDI spec and did some little tests with a prototype we have here and I am facing a issue when I deploy our application at GF 4 (which has guava as ine of the dependencies):
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
Basically I am facing it because guava has some classes annotated with @Inject and the container by default are scanning all the deps.
I have read the spec and for me it is not clear what the default behaviour is, if the container should or not scan all the dependencies when my app is supposedly following 1.0 spec (see our beans.xml above). Digging a little bit more, I found a issue [1] which says basically that 'Auto-discover is false by default in CDI 1.1 and the attribute is required...', which for me means that by default the container should work as CDI 1.0 at this matter. R eading the spec a little further I found ' For compatibility with Contexts and Dependency 1.0, products must contain an option to cause an archive to be ignored by the container when no beans.xml is present.' (which is the case for guava library) which could means that by default the container will not work as expected by CDI 1.0, so we have an incompatible change here.
Our beans.xml file has just this content:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>
My question here is: Am I facing a issue at Weld/GF 4 (glassfish-4.0-b86) or it is the default behaviour expected for CDI 1.1 specification?
IMHO this behaviour should be clear at the specification, maybe following as did by JSR 344 adding a 'Breakages in Backward Compatibility' section for changelog section if it is the case.
I am sorry if this question have already been asked, but I was unable to find it (I swear I tried :).
Thanks in advance.
[1] https://issues.jboss.org/browse/CDI-321
--
Michel Graciano
Pesquisa e Desenvolvimento
Betha Sistemas Ltda.
11 years, 7 months
Lifecycle Callback Interceptor and @Target "METHOD"
by Jens Schumann
Hi all!
While testing Weld 2.0.0.CR4 I have been running into a DefinitionException because of an interceptor that contains one @AroundInvoke and one @PostConstruct method. Since I use this interceptor at class AND method level it declares @Target({ElementType.METHOD, ElementType.TYPE}). The error message seems to indicate that I can not have a lifecycle callback interceptor with @Target METHOD:
"WELD-000619 An interceptor for lifecycle callbacks Interceptor XX declares and interceptor binding interface YYY with METHOD as its @Target."
Is this true? I just checked the current CDI 1.1 and Interceptor 1.2 spec and could not find this kind of restriction.
Jens
11 years, 7 months
BBD in CDI-1.1
by Mark Struberg
public void addQualifier(AnnotatedType<? extends Annotation> annotatedType)
the same exists for IntercpetorBinding
I think this is a leftover of the reverted CDI-286 feature?
LieGrue,
strub
11 years, 7 months
[JBoss JIRA] (CDI-369) check required by #testFireEventWithNonRuntimeBindingTypeFails is too late
by Gerhard Petracek (JIRA)
[ https://issues.jboss.org/browse/CDI-369?page=com.atlassian.jira.plugin.sy... ]
Gerhard Petracek commented on CDI-369:
--------------------------------------
created here, because a clear rule for checking it should be part of the specification
> check required by #testFireEventWithNonRuntimeBindingTypeFails is too late
> --------------------------------------------------------------------------
>
> Key: CDI-369
> URL: https://issues.jboss.org/browse/CDI-369
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 1.0
> Reporter: Gerhard Petracek
>
> as discussed with pete this ticket is based on https://issues.apache.org/jira/browse/OWB-798
> the check needed to pass org.jboss.jsr299.tck.tests.event.bindingTypes.EventBindingTypesTest#testFireEventWithNonRuntimeBindingTypeFails is slow and even more important too late.
> we can do the same check (once) during bootstrapping before adding an observer.
> reason why we don't need this check after bootstrapping:
> if an invalid event (with an invalid qualifier) is used in a dyn. #fire, we can ignore the invalid literal-instance, because there is no corresponding observer (qualifiers of the observers would be checked during bootstrapping -> the startup would fail, if there is such an invalid observer).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-369) check required by #testFireEventWithNonRuntimeBindingTypeFails is too late
by Gerhard Petracek (JIRA)
Gerhard Petracek created CDI-369:
------------------------------------
Summary: check required by #testFireEventWithNonRuntimeBindingTypeFails is too late
Key: CDI-369
URL: https://issues.jboss.org/browse/CDI-369
Project: CDI Specification Issues
Issue Type: Bug
Components: Events
Affects Versions: 1.0
Reporter: Gerhard Petracek
as discussed with pete this ticket is based on https://issues.apache.org/jira/browse/OWB-798
the check needed to pass org.jboss.jsr299.tck.tests.event.bindingTypes.EventBindingTypesTest#testFireEventWithNonRuntimeBindingTypeFails is slow and even more important too late.
we can do the same check (once) during bootstrapping before adding an observer.
reason why we don't need this check after bootstrapping:
if an invalid event (with an invalid qualifier) is used in a dyn. #fire, we can ignore the invalid literal-instance, because there is no corresponding observer (qualifiers of the observers would be checked during bootstrapping -> the startup would fail, if there is such an invalid observer).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
review questions 1/n
by Mark Struberg
Hi Pete!
Just a few random questions which popped up
@Vetoed on packages only excludes classes from the very package, but not from sub-packages, right?
@WithAnnotations is not yet a Qualifier. That would have allowed us to reuse standard CDI mechanics.
LieGrue,
strub
11 years, 8 months
beans exclude
by Mark Struberg
Another one:
With the auto-pickup of all beans we have problems to provide libs for CDI-1.0 and 1.1.
In cdi-1.1 you can define a beans.xml with scan-mode none, but that beans.xml would trigger exactly the opposite in CDI-1.0 containers!
Thus I like to introduce a paragraph:
"If there is a file META-INF/nobeans.xml in absence of a beans.xml, the scan mode for this BDA is none"
Effectively means: if you don't like to get this jar picked up by neither cdi-1.1 nor 1.0 containers you don't write a beans.xml with scan-mode none but have no beans.xml at all but an empty nobeans.xml marker file.
Not sure if it's too late to go into the spec, but it would help if OWB and Weld use this mechanism at least. And we add it to the spec in a MR.
Another topic:
ProcessAnnotatedType has no info about the id you can add with addAnnotatedType(Class, String). Nor has AnnotatedType. That might be an issue for some use cases, isn't? I'd at least supposed to get it in ProcessSyntheticAnnotatedType.
LieGrue,
strub
11 years, 8 months
