Getting injection point from Bean#create
by arjan tijms
Hi,
In a producer method it's trivial to get access to an InjectionPoint
instance representing the point where the value produced by the
producer will be injected.
When registering a Bean manually from an extension using
AfterBeanDiscovery#addBean, this is not immediately obvious.
After some fumbling with the CDI APIs I came up with the following
code that seems to work on both Weld and OWB (didn't test CanDI yet).
It uses a small "dummy" class, which is used to grab an InjectionPoint off:
In a Bean:
public Object create(CreationalContext<Object> creationalContext) {
InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
creationalContext
);
With InjectionPointGenerator being the following class:
public class InjectionPointGenerator {
@Inject
private InjectionPoint injectionPoint;
}
And resolve being the following method:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
As mentioned, while this seems to work, I wonder if it's the best approach.
Kind regards,
Arjan
8 years, 11 months
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
I fear there pretty much _is_ ambiguity with this interpretation. Because in all the other bean archives - where the @Alternative @Specializes is *not* active there is NO bean satisfying these types at all! Because for *them* the original bean is disabled because it is 'specialized away' but the @Alternative @Specializes bean is not enabled neither...
This app imo shouldn't even start. Because if it does then it will blow up at runtime.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-563 started by Antoine Sabot-Durand.
------------------------------------------------
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR2
>
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-563:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR2
>
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-563?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-563:
-------------------------------------
Fix Version/s: 2.0-EDR2
> Event.fireAsync() - clarify the usage of the returned CompletionStage
> ---------------------------------------------------------------------
>
> Key: CDI-563
> URL: https://issues.jboss.org/browse/CDI-563
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Affects Versions: 2.0-EDR1
> Reporter: Martin Kouba
> Fix For: 2.0-EDR2
>
>
> So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.:
> {quote}
> * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method.
> {quote}
> So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread:
> {code:java}
> event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!"));
> {code}
> And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-574:
------------------------------------------
Guys. I already gave my opinion during last meeting:
* alternatives can be selected at bean archive level
* specialization is global
* If an alternative is selected in at least one bean archive the bean is enabled.
* If a specializes bean is enabled, the bean that was specialized is disabled
There is no ambiguity here.
I agree that it's not an intuitive behavior but now it's written in black on white in the spec.
On the other hand I find the topic very "corner-case-ish" : the use case described suppose that I own the corresponding bean archive so I can change their config (or use {{@Priority}}) to obtain the expected behavior.
Working on a global config proposal (as we spoke during face to face) would more helpful than continuing this thread IMO.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
But all those rules explicitly ONLY apply for specialization by ENABLED beans as defined in 5.1.2. According to the spec the observer method in the base class must get used if there are only non-enabled @Alternatives.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-574:
----------------------------------
No, it's not. The current wording of the spec does not define specialization on the bean archive level. It only states that if an enabled bean specializes a second bean, the second bean is never instantiated. Anyway, it seems it does not makes sense to continue on this discussion as we can't agree on this. It's up to the spec lead.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-574:
-----------------------------------
But your quote is only true for an 'enabled' specialization. Means if they have @alternative but are never activated then it is disabled.
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-574:
----------------------------------
bq. what happens with an observer in there?
Sorry, I'm not sure I understand your question. However, if there is an observer declared on the specialized bean, then this observer is ignored. See also 4.3. Specialization: _"Even if the second bean defines a producer or observer method, the method will never be called."_
> Should a disabled @Specialized disable a second bean?
> -----------------------------------------------------
>
> Key: CDI-574
> URL: https://issues.jboss.org/browse/CDI-574
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Inheritance and Specialization
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
>
> In CDI specification Section 4.3:
> When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called.
> The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean?
> Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean.
> This needs to be clarified.
> In more details:
> I have an application containing two wars.
> testDiffBDA.war
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
> @Inject CounterProducerConsumerModified2 bean;
> beans-xml-modified2.jar
> containing one bean and an empty-ish beans.xml :
> @Inject@CounterModifiedQualifier String modifiedProducer;
> beans-xml-modified.jar.jar
> CounterModifiedQualifier (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative specialized bean)
> beans.xml
> <alternatives>
> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class>
> </alternatives>
> My application failed deployment with the error on Weld but worked on OpenWebBeans
> {code}
> [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier
> at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
> at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
> {code}
> After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier.
> From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
> My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month