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