Hi Emily,
the problem is Specialization is not defined per bean archive but per application. A bean is either specialized or not. Note that specialization is not tied to alternatives.
WRT your use-case: the specializing bean should be enabled globally or in each bean archive which is using the specialized bean.
Martin
Dne 23.11.2015 v 10:54 Emily Jiang napsal(a):
Thank you Tom and Matej for your response!
The alternative was enabled in the archive beans-xml-modified.jar, but
it is not enabled in the archive beans-xml-modified2.jar. The issue is
not with alternative but with Specialized.
At the moment, Weld specialized is effective even if itself is not
enabled, which is not desirable because it disables other bean but
itself is not enabled. As a consequence, this causes deployment error.
The CDI 1.2 section 4.3 spec says:
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.
It is true the above sentence comments about an enabled bean. It hits an
disabled bean should not specialize a second bean. If you guys think it
is unclear, can we update the spec to clarify this scenario?
By the way, OWB and Weld behave differently (Weld thinks a disabled bean
still specializes a second bean while OWB thinks a disabled bean does
NOT specialize a second bean). This is something we can leave to
implementation. We should spec it!
On Mon, Nov 23, 2015 at 8:45 AM, Matej Novotny <manovotn@redhat.com
<mailto:manovotn@redhat.com>> wrote:
Hello Emily
I agree with Tom. In your case, specialized producer is enabled (via
beans.xml) although only per bean archive.
And about this:
>>From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not.
It is true, however the spec doesn't define how does a @Specialized
bean behave when it is disabled (or at least I haven't found that bit).
So this leaves it up to implementation and I can't really see a
problem with it. Why would you create a @Specialized bean and
disable it afterwards (with no other @Specialized and/or
@Alternative active)?
Matej
----- Original Message -----
From: "Tomas Remes" <tremes@redhat.com <mailto:tremes@redhat.com>>
To: "Emily Jiang" <emijiang6@googlemail.com
<mailto:emijiang6@googlemail.com>>
Cc: "cdi-dev" <cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
Sent: Monday, November 23, 2015 8:33:44 AM
Subject: Re: [cdi-dev] Clarification on 4.3 Specialization
Hi Emily,
I am not sure I follow. What is disabled?
AlternativeCounterProducerModified? I can see
AlternativeCounterProducerModified is enabled in beans.xml of the
given bean archive and it means it is selected alternative only per
the bean archive. So I can't see any problem (or maybe I don't fully
understand).
Tom
----- Original Message -----
From: "Emily Jiang" <emijiang6@googlemail.com
<mailto:emijiang6@googlemail.com>>
To: "cdi-dev" <cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
Sent: Sunday, November 22, 2015 10:42:29 PM
Subject: Re: [cdi-dev] Clarification on 4.3 Specialization
any thoughts?
Should a bean with @Specialize disable a bean even if it is disabled
itself?
On Thu, Nov 19, 2015 at 10:09 AM, Emily Jiang <ejiang@apache.org <mailto:ejiang@apache.org>emijiang6@googlemail.com <mailto:emijiang6@googlemail.com> > wrote:
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
[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)
--
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.
I also checked the spec:
@Alternative @Specializes
public class MockAsynchronousService extends AsynchronousService {
...
}
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. I
would like to know what other people think.
Thanks
Emily
=================
Emily Jiang
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org <mailto:ejiang@apache.org>
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such information.
--
Tomas Remes
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and
other intellectual property rights inherent in such information.
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org <mailto:ejiang@apache.org>
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic