With other words: this part of the TCK should not have been using Arquillian in the first place.
LieGrue, strub > Am 30.07.2017 um 23:59 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Just exclude these tests and remplace them by webbeans-se normal tests. > This is good enough and doesnt require arquillian hacks. > > Le 30 juil. 2017 23:56, "John D. Ament" <johndam...@apache.org> a écrit : > > On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> Se code can work with arquillian tuning the scanner in owb.props but not >> sure it does wirrh it if we cover the tests in standalone already. Wdyt? >> > > Romain, I have no idea what you're asking here. > > >> >> Le 30 juil. 2017 22:29, "John D. Ament" <johndam...@apache.org> a écrit : >> >>> Mark, >>> >>> Sure, its this TCK test in particular: >>> https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/ >>> src/main/java/org/jboss/cdi/tck/tests/se/container/ >>> BootstrapSEContainerTest.java#L57 >>> >>> From looking at what they're doing, it seems like they're trying to >> create >>> an isolated classpath using the Arquillian SE container, and expecting >> the >>> beans to be discovered from there. However, the SE container OWB is >>> initializing ends up mixing ShrinkWrap and XBean behavior, which causes >> JAR >>> discovery to behave a bit different. >>> >>> BTW, I did try changing the protocol, no luck as the JAR generated isn't >> a >>> real JAR. >>> >>> John >>> >>> On Sun, Jul 30, 2017 at 3:52 PM Mark Struberg <strub...@yahoo.de.invalid >>> >>> wrote: >>> >>>> Hi John! >>>> >>>> We actually don't use xbean at all in the arquillian adapter. >>>> The scanning is done manually. You can dig that in the >>>> OwbArquillianScannerService. >>>> Can you share your setup? Probably might help a bit later. >>>> >>>> LieGrue, >>>> strub >>>> >>>>> Am 30.07.2017 um 20:23 schrieb John D. Ament <johndam...@apache.org >>> : >>>>> >>>>> Hi All, >>>>> >>>>> So I've been trying to dig into why OWB's CDI TCK tests are >> failing. I >>>>> have it down to 22 failures that should mostly be passing (or are >>> failing >>>>> in the wrong spot). The most common failure is because of this: >>>>> >>>>> Caused by: java.lang.UnsupportedOperationException: unsupported >>> archive >>>>> type: archive:8a164bf7-f1d7-407e-b612-633720f769f1.jar/ >>>>> at >>>>> >>>> org.apache.xbean.finder.archive.ClasspathArchive. >>> archive(ClasspathArchive.java:87) >>>>> at >>>>> >>>> org.apache.webbeans.corespi.scanner.xbean.CdiArchive.< >>> init>(CdiArchive.java:67) >>>>> >>>>> I'm not sure if this is an XBean issue or an OWB issue. Basically, >>> when >>>>> bootstrapping CDI SE, we're getting some shrinkwrap JARs on the >>> classpath >>>>> (which is on purpose, I think they're trying to make a CDI bean >> archive >>>> in >>>>> addition to what's in the SE container). XBean doesn't know what > the >>>>> "archive" protocol means. I suspect if the first if statement in >>>>> ClasspathArchive were changed to (line >>>>> 53): if(location.getProtocol().equals("jar") || >>>>> location.getProtocol().equals("archive")) { then it would fix it, > but >>> not >>>>> 100% sure. >>>>> >>>>> John >>>> >>>> >>> >>
