[cdi-dev] bean archives

Mark Struberg struberg at yahoo.de
Mon May 4 03:59:30 EDT 2015


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 at redhat.com>:
> 
> 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 at googlemail.com>
>> Date: Sat, May 2, 2015 at 10:21 PM
>> Subject: Re: [cdi-dev] bean archives
>> To: Mark Struberg <struberg at yahoo.de>
>> 
>> 
>> 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 at yahoo.de> 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 at sabot-durand.net> 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 at googlemail.com> 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 at apache.org
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at 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 at 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 at apache.org
>> 
>> 
>> 
>> -- 
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang at apache.org
>> 
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> 
>> cdi-dev at 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 at 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.




More information about the cdi-dev mailing list