You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "John D. Ament" <jo...@apache.org> on 2017/07/30 18:23:41 UTC
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: 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
Re: XBean & ShrinkWrap archives
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <jo...@apache.org>:
> 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 <jo...@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 <struberg@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 <jo...@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
> <struberg@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 <
> >> rmannibucau@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" <jo...@apache.org> a
> >> écrit
> >> >> :
> >> >>>
> >> >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
> >> >> rmannibucau@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" <jo...@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
> >> >> <struberg@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 <
> >> johndament@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
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
>
Re: XBean & ShrinkWrap archives
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@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 <st...@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 <jo...@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 <struberg@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 <
>> rmannibucau@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" <jo...@apache.org> a
>> écrit
>> >> :
>> >>>
>> >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
>> >> rmannibucau@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" <jo...@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
>> >> <struberg@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 <
>> johndament@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
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>
>> >>
>>
>>
Re: XBean & ShrinkWrap archives
Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@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 <jo...@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 <struberg@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 <
> rmannibucau@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" <jo...@apache.org> a
> écrit
> >> :
> >>>
> >>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
> >> rmannibucau@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" <jo...@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
> >> <struberg@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 <
> johndament@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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: XBean & ShrinkWrap archives
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@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 <st...@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 <rmannibucau@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" <jo...@apache.org> a écrit
>> :
>>>
>>> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
>> rmannibucau@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" <jo...@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
>> <struberg@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 <johndament@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: XBean & ShrinkWrap archives
Posted by "John D. Ament" <jo...@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 <st...@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 <rmannibucau@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" <jo...@apache.org> a écrit
> :
> >
> > On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <
> rmannibucau@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" <jo...@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
> <struberg@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 <johndament@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
> >>>>
> >>>>
> >>>
> >>
>
>
Re: XBean & ShrinkWrap archives
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <rm...@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" <jo...@apache.org> a écrit :
>
> On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <rm...@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" <jo...@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 <struberg@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 <johndament@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
>>>>
>>>>
>>>
>>
Re: XBean & ShrinkWrap archives
Posted by Romain Manni-Bucau <rm...@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" <jo...@apache.org> a écrit :
On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <rm...@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" <jo...@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 <struberg@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 <johndament@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
> > >
> > >
> >
>
Re: XBean & ShrinkWrap archives
Posted by "John D. Ament" <jo...@apache.org>.
On Sun, Jul 30, 2017 at 4:36 PM Romain Manni-Bucau <rm...@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" <jo...@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 <struberg@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 <johndament@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
> > >
> > >
> >
>
Re: XBean & ShrinkWrap archives
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <jo...@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 <st...@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 <jo...@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
> >
> >
>
Re: XBean & ShrinkWrap archives
Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@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 <jo...@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
>
>
Re: XBean & ShrinkWrap archives
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@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