Re: XBean & ShrinkWrap archives

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

Re: XBean & ShrinkWrap archives

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

Re: XBean & ShrinkWrap archives

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

Re: XBean & ShrinkWrap archives

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

Re: XBean & ShrinkWrap archives

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

Re: XBean & ShrinkWrap archives

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 : > > Just exclude these tests and remplace them by webbeans-se normal tests. > This is good enough and

Re: XBean & ShrinkWrap archives

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" a écrit : On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau wrote: > Se code

Re: XBean & ShrinkWrap archives

On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau 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

Re: XBean & ShrinkWrap archives

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? Le 30 juil. 2017 22:29, "John D. Ament" a écrit : > Mark, > > Sure, its this TCK test in particular: >

Re: XBean & ShrinkWrap archives

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

Re: XBean & ShrinkWrap archives

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

XBean & ShrinkWrap archives

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: