Hi Aslak, I've now fixed it with a dirty hack. So no hurry. But we should finally setup a kind of TCK for CDI arquillian containers.
LieGrue, strub ----- Original Message ----- > From: Aslak Knutsen <[email protected]> > To: Mark Struberg <[email protected]> > Cc: deltaspike <[email protected]> > Sent: Sunday, September 30, 2012 10:19 PM > Subject: Re: CDI Extension testing with Arquillian > >T ry to build arquillian-container-weld master branch. > > https://github.com/arquillian/arquillian-container-weld/commit/ddba36c6bc36848364c606adf1001eafbc3d2805 > > We should push a new version, just haven't gotten to it. > > Extensions work for JavaArchives but not WebArchives (due to > META-INF/services 'redirect'). The commit above fix this for the Weld > container. Might look at using the same CL stuff for OWB. > > -aslak- > > On Sun, Sep 30, 2012 at 9:29 PM, Mark Struberg <[email protected]> wrote: >> Hi folks! >> >> I have a small problem with testing the AbstractContext with Arquillian. >> I wrote a DummyContext + DummyContextExtension and add them to my > deployment (see the last commit) but fail to test it. >> >> It seems that neither the Weld Arquillian container not OWB (didn't > test others) take the Extensions from the ShrinkWrap archive but from the > available ClassPath. >> >> The registered Extension in >> >> return ShrinkWrap >> .create(WebArchive.class, > "abstractContextTest.war") >> .addAsLibraries(ArchiveUtils.getDeltaSpikeCoreArchive()) >> .addAsLibraries(testJar) >> .addAsWebInfResource(EmptyAsset.INSTANCE, > "beans.xml") >> .addAsServiceProvider(Extension.class, > DummyScopeExtension.class); >> >> just has no effect at all. >> >> How to deal with that? >> >> The easy solution would be to just add the Extension to the test classpath > via a META-INF/services/... file. >> For now this seems the best we can do, but imo that's no clean final > solution, wdyt? >> >> LieGrue, >> strub >
