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 >>>>>> >>>>>> >>>>> >>>> >> >>
