Agreed, when I first looked at it. Not so much afterwards. Andrew (ALR) was working on an idea a long time ago of having an "SE Container" where it was a fully isolated JVM that you could just push classes to. I think that's what they were trying to do here.
I raised my first TCK issue today :-) I'll raise another for this (was thinking about it anyways), since I'm really not sure what they were going for with this test. Would it be an issue to just duplicate the tests here? John On Sun, Jul 30, 2017 at 6:01 PM Mark Struberg <strub...@yahoo.de.invalid> wrote: > 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 > >>>> > >>>> > >>> > >> > >
