On 05/03/2015 10:44 PM, Emily Jiang wrote: How does it break compatibility?

The CDI-1.0 TCK initially did not check anything in that regard. A test got added in a _very_ late version. This was in fact released AFTER CDI-1.1 was published if I remember correctly. So this version is not even part of the EE6 TCK… LieGrue, strub

No, it's not the case that "all CDI 1.0 implementor checks all jars having beans.xml and then merge the classes to the module bean archive". Some CDI 1.0 implementations implement the spec properly including the fine granularity of Chapter 12, some don't and since the TCK for CDI 1.0 is does not test much in this area it allows both groups to pass. That was fixed in subsequent TCK releases. On 05/04/2015 11:52 PM, Emily Jiang wrote:

That’s factually wrong. Section 5 defines BDA different than Section 12. This is an unresolved issue until today. Or section 12. Both ways are perfectly backward incompatible. If you drop BDA in section 5 then you break EE modularity and compatibility to EE6 servers (incuding RI). If you drop BDA in section 12 then you break scanning. We really need to handle this carefully. Imo we should finally accept that there are 2 different ‚BDA‘ use cases and they both need a different Term. What about using the term BDA for section 12 and only for scanning. And the term ‚EE module‘ for section 5 (visibility) + interceptors, alternatives and decorators. That is basically how the EE6 RI behaved and what is the best for users. It also allows for _much_ better performance! And also please acknowledge the Alternatives-per-JAR is a major PITA in _real_ projects. LieGrue, strub > Am 05.05.2015 um 10:19 schrieb Emily Jiang <emijiang6(a)googlemail.com&gt;: > > > On Tue, May 5, 2015 at 6:06 AM, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: > No, it's not the case that "all CDI 1.0 implementor checks all jars having beans.xml and then merge the classes to the module bean archive". Some CDI 1.0 implementations implement the spec properly including the fine granularity of Chapter 12, some don't and since the TCK for CDI 1.0 is does not test much in this area it allows both groups to pass. That was fixed in subsequent TCK releases. > > > On 05/04/2015 11:52 PM, Emily Jiang wrote: >> ah. ok. For cdi 1.0, if all the implementor checks all jars having beans.xml and then merge the classes to the module bean archive, this will be fine. I think a spec issue will be raised to update section 5. >> >> On Mon, May 4, 2015 at 8:59 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> The CDI-1.0 TCK initially did not check anything in that regard. A test got added in a _very_ late version. This was in fact released AFTER CDI-1.1 was published if I remember correctly. So this version is not even part of the EE6 TCK… >> >> LieGrue, >> strub >> >> > Am 04.05.2015 um 09:07 schrieb Jozef Hartinger <jharting(a)redhat.com&gt;: >> > >> > Yes, chapter 5 is a bit confusing when it comes to composite Java EE modules. Comments inline: >> > >> > On 05/03/2015 12:20 AM, Emily Jiang wrote: >> >> I agree with Mark. I am confused about section 5 and section 12. Weld-2 leaves the work of specifying the bean archive to the integrator. I am wondering how the new version of app server using Weld-2 can pass the CDI 1.1/1.2 CTS at all if the integrator creates its bean archives based on section 12. >> > The TCK for CDI 1.0, 1,1 and 1.2 expect Chapter 12 to be implemented. Therefore, implementing bean archive as defined in Chapter 12 is the right approach for a Weld integrator. >> >> >> >> I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?), is based on section 5. Can someone confirm? The spec needs to be updated to remove the conflict between section 5 and section 12. >> >> ---------- Forwarded message ---------- >> >> From: Emily Jiang <emijiang6(a)googlemail.com&gt; >> >> Date: Sat, May 2, 2015 at 10:21 PM >> >> Subject: Re: [cdi-dev] bean archives >> >> To: Mark Struberg <struberg(a)yahoo.de&gt; >> >> >> >> >> >> I agree with Mark. I am confused about section 5 and section 12. Weld-2 leaves the work of specifying the bean archive to the integrator. I am wondering how the new version of app server using Weld-2 can pass the CDI 1.1/1.2 CTS at all if the integrator creates its bean archives based on section 12. >> >> >> >> I am guessing CDI 1.1/1.2 cts, the updated version of CDI 1.0(?), is based on section 5. Can someone confirm? The spec needs to be updated to remove the conflict between section 5 and section 12. >> >> >> >> On Sat, May 2, 2015 at 3:47 PM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: >> >> Actually the rules are still not clear. Section 5 and 12 contradict each other. The EE6 RI, JBossAS6 and TomEE and WAS did behave like in section 5 (1 BDA per ee-module) whereas Weld-2 behaves like in section 12. >> >> >> >> LieGrue, >> >> strub >> >> >> >> >> >> >> >> On Saturday, 2 May 2015, 10:13, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: >> >> >> >> >> >> Hi Emily, >> >> >> >> The rules) apply to each jar (archive). There is no merging, thus an app can contain three types of archives : >> >> Non bean archives, >> >> Implicit bean archives, >> >> Explicit bean archives. >> >> >> >> Antoine Sabot-Durand >> >> >> >> >> >> Le 1 mai 2015 à 23:03, Emily Jiang <emijiang6(a)googlemail.com&gt; a écrit : >> >> >> >>> >> >>> I have a question on bean archives. >> >>> >> >>> For the jars under web-inf\lib, are they individual bean archives or they should be merged with web-inf\classes files and use the beans.xml under web-inf\ to form one bean archive? >> >>> >> >>> >> >>> If they are merged together to form one bean archive, what will happen if they have their own beans.xml under Meta-inf dir? >> >>> >> >>> Below is the what spec says, but it does not mention the jar under web-inf\lib. The spec should make this situation clear. >> >>> >> >>> In the CDI1.2 spec: >> >>> When determining which archives are bean archives, the container must consider: >> >>> • Library jars, EJB jars or application client jars >> >>> • The WEB-INF/classes directory of a war >> >>> • Directories in the JVM classpath >> >>> The container is not required to support application client jar bean archives. >> >>> A Java EE container is required by the Java EE specification to support Java EE modules. Other >> >>> containers may or may not provide support for war, EJB jar or rar bean archives. >> >>> The beans.xml file must be named: >> >>> • META-INF/beans.xml , or, >> >>> • in a war, WEB-INF/beans.xml or WEB-INF/classes/META-INF/beans.xml. >> >>> >> >>> >> >>> >> >>> -- >> >>> Thanks >> >>> Emily >> >>> ================= >> >>> Emily Jiang >> >>> ejiang(a)apache.org >> >>> _______________________________________________ >> >>> cdi-dev mailing list >> >>> cdi-dev(a)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. >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> cdi-dev(a)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(a)apache.org >> >> >> >> >> >> >> >> -- >> >> Thanks >> >> Emily >> >> ================= >> >> Emily Jiang >> >> ejiang(a)apache.org >> >> >> >> >> >> _______________________________________________ >> >> cdi-dev mailing list >> >> >> >> cdi-dev(a)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. >> > >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev(a)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(a)apache.org > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang(a)apache.org

2015-05-05 13:39 GMT+02:00 Jozef Hartinger <jharting(a)redhat.com&gt;: Didn't check glassfish but most of EE 6 servers didn't respect it cause it was just impossible to write an application using a CDI library with such a rule. I think it should be taken into account anyway because it is an important feedback to the spec.

I raised https://issues.jboss.org/browse/CDI-533 for spec update. On Mon, May 11, 2015 at 1:43 PM, Emily Jiang <emijiang6(a)googlemail.com&gt; wrote: -- Thanks Emily ================= Emily Jiang ejiang(a)apache.org