Ok, just chatted with Mark. I'm going to get the SE TCK running in a new module, webbeans-se-tck. There's a different arquillian container to use (the SE container) which is what Weld's doing to run these tests. I'll hopefully get a patch out for this tonight.
John On Sun, Jul 30, 2017 at 6:29 PM John D. Ament <johndam...@apache.org> wrote: > I have a local test working. > > It's not going to work too cleanly, but its doable. > > If you look at this test for instance: > https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/java/org/jboss/cdi/tck/tests/se/discovery/trimmed/TrimmedBeanArchiveSETest.java > , > its dependent on having a bean archive with this beans.xml file > https://github.com/cdi-spec/cdi-tck/blob/2.0.0.Final/impl/src/main/resources/org/jboss/cdi/tck/tests/se/discovery/trimmed/beans.xml > > Maybe we'll get lucky and this is the only case of a special beans.xml, > but we may need multiple test projects to accomplish it (maybe some > examples?) > > John > > > On Sun, Jul 30, 2017 at 6:19 PM Mark Struberg <strub...@yahoo.de.invalid> > wrote: > >> Well, we would need to keep the JBoss copyright. >> Which is something I'd rather like to avoid because it's essentially just >> a test. >> >> I'm currently moving from the tomcat7-m-p to cargo-maven2-plugin. >> I can help and take a look into those SE parts affter all that is running >> again. >> >> LieGrue, >> strub >> >> >> > Am 31.07.2017 um 00:11 schrieb John D. Ament <johndam...@apache.org>: >> > >> > 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 >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >> >> >> >> >>
