side note: if we can get tested anyway on se module, without arquillian, to ensure we work OOTB and not that arquillian works (which is a pitfall of weld and owb ATM cause they dont dump and deploy archives for speed reasons). we can also just dump the archive and launch a new jvm for tcks...
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-07-31 0:45 GMT+02:00 John D. Ament <[email protected]>: > 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 <[email protected]> > 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 <[email protected] > > > > 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 <[email protected]>: > >> > > >> > 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 > <[email protected] > >> > > >> > 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 < > >> [email protected] > >> >>> : > >> >>> > >> >>> 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" <[email protected]> a > >> écrit > >> >> : > >> >>> > >> >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau < > >> >> [email protected]> > >> >>> 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" <[email protected]> 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 > >> >> <[email protected] > >> >>>>> > >> >>>>> 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 < > >> [email protected] > >> >>>>> : > >> >>>>>>> > >> >>>>>>> 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 > >> >>>>>> > >> >>>>>> > >> >>>>> > >> >>>> > >> >> > >> >> > >> > >> >
