I think how this works is interpreted differently by everyone. So for now we
assume that it doesn't work there. And for CDI 1.1 we explicitly list it as a
location to be supported and force people to support it (Stuart).
On 20 Feb 2012, at 15:37, Mark Struberg wrote:
> The CDI spec might be slightly ambiguous:
>
> section 12.1 defines what a 'Bean Archive' is:
>
> ...
> * A directory in the JVM classpath is a bean archive if it has a file named
> beans.xml in the META-INF directory.
>
>
> The question now is if WEB-INF/classes is a 'directory in the JVM classpath'.
> Well, the JVM Classpath only contains URLs and the VM spec doesn't say
> anything about 'directories' at all imo. Thus
> WEB-INF/classes/META-INF/beans.xml does qualify imo.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Dan Allen <dan.j.al...@gmail.com>
>> To: deltaspike-dev@incubator.apache.org
>> Cc:
>> Sent: Monday, February 20, 2012 4:10 PM
>> Subject: Re: Issues with arquillian archives on WebLogic 12c -> wrong
>> beans.xml file location
>>
>> T he location of beans.xml in a war that Rudy suggests is correct, according
>> to the spec.
>>
>> We've discussed this issue frequently on various mailinglists and forums
>> because the general consensus is that a web archive should support honor
>> either location. The roadblock at the moment is that the only valid
>> location according to the spec document is WEB-INF/beans.xml, per chapter
>> 12.1.
>>
>> The WEB-INF/classes directory of a war is a bean archive if there is a file
>>> named beans.xml in the WEB-INF directory of the war.
>>> ...
>>>
>>> - In an application deployed as a war, the container searches every
>>> bean archive bundled with or referenced by the war. The bean archives
>> might
>>> be library jars or the WEB-INF/classes directory.
>>>
>>> Arquillian requires the BeanManager to be available to the war, so the
>> beans.xml needs to be placed in the compliant location.
>>
>> Note that CDI implementations have added support for
>> WEB-INF/classes/beans.xml to support jetty:run and tomcat:run development
>> deployments. Those are non-standard atm.
>>
>> I believe this is a spec change requested for CDI 1.1 (though I don't see
>> it atm).
>>
>> -Dan
>>
>> On Mon, Feb 20, 2012 at 04:13, Gerhard Petracek
>> <gerhard.petra...@gmail.com>wrote:
>>
>>> hi rudy,
>>>
>>> thx for the info.
>>> i've seen the same effect with the test-cases of the security-module
>> (but
>>> there the constellations are more complex).
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2012/2/20 Rudy De Busscher <rdebussc...@gmail.com>
>>>
>>>> Hi all,
>>>>
>>>> I'm trying to run the DeltaSpike integration tests on the Oracle
>> WebLogic
>>>> 12C server.
>>>>
>>>> And i'm getting the following exceptions (related
>>>> to ExcludeIntegrationTest, the first test)
>>>>
>>>> *Weblogic console*
>>>>
>>>> *org.jboss.arquillian.testenricher.cdi.container.BeanManagerProducer
>>>> lookup*
>>>> *INFO: BeanManager not found*
>>>>
>>>> *test log file*
>>>>
>>>>
>>>>
>>>
>> *simpleCheckOfBeansInPackage(org.apache.deltaspike.integration.core.api.exclude.ExcludeIntegrationTest)
>>>> Time elapsed: 0.003 sec <<< ERROR!*
>>>> *java.lang.IllegalStateException: No
>>>> org.apache.deltaspike.core.api.provider.BeanManagerProvider in place!
>>>> Please ensure that you configured the CDI implementation of your
>> choice
>>>> properly. If your setup is correct, please clear all caches and
>> compiled
>>>> artifacts.*
>>>> * at
>>>>
>>>>
>>>
>> org.apache.deltaspike.core.api.provider.BeanManagerProvider.getInstance(BeanManagerProvider.java:88)
>>>> *
>>>> * at
>>>>
>>>>
>>>
>> org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:258)
>>>> *
>>>> * at
>>>>
>>>>
>>>
>> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:78)
>>>> *
>>>> * at
>>>>
>>>>
>>>
>> org.apache.deltaspike.integration.core.api.exclude.ExcludeIntegrationTest.simpleCheckOfBeansInPackage(ExcludeIntegrationTest.java:94)
>>>> *
>>>>
>>>>
>>>> However, a test application that uses the following code in a get
>> method
>>> of
>>>> a property
>>>>
>>>> * AlwaysActiveBean testBean =
>>>> BeanProvider.getContextualReference(AlwaysActiveBean.class, true);*
>>>> * BeanManager manager;*
>>>> * try {*
>>>> * InitialContext ic = new InitialContext();*
>>>> * manager = (BeanManager)
>> ic.lookup("java:comp/BeanManager");*
>>>> * } catch (Exception e) {*
>>>> * throw new RuntimeException(e);*
>>>> * }*
>>>>
>>>> succeed and I have a value for testBean and manager.
>>>>
>>>> So there is nothing wrong with CDI (and deltaspike) on WLS.
>>>>
>>>> By uncommenting the following in arquillian.xml
>>>> * <engine>*
>>>> * <property
>> name="deploymentExportPath">target/</property>*
>>>> * </engine>*
>>>>
>>>> I see that the beans.xml file is located in a top-level META-INF
>>> directory
>>>> and not in WEB-INF or WEB-INF\classes\META-INF.
>>>>
>>>> So probably WLS decides that the WAR has nothing to do with CDI and
>> thus
>>> is
>>>> not available.
>>>>
>>>> Replacing
>>>> *.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");*
>>>> by
>>>> *.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");*
>>>>
>>>> the test works on WLS (well I have other issues but CDI and
>> deltaSpike
>>> is
>>>> correctly loaded) and JBoss/GlassFish
>>>>
>>>> I'll create a *JIRA ticket *to change the deployment methods of
>> the
>>> current
>>>> integration tests
>>>>
>>>> Sorry for this long post, but it is important for the compatibility of
>>>> future integration tests .
>>>>
>>>> Regards
>>>> Rudy
>>>>
>>>>
>>>> --
>>>> Rudy De Busscher
>>>> http://www.c4j.be
>>>>
>>>
>>
>>
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://google.com/profiles/dan.j.allen
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
