[jira] [Updated] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated OWB-1206:
---
Attachment: OWB_1206_v2.patch

Here's a better patch, created an owb-se-tck package to run.  It's a bit of a 
pain but the test harness will end up being the simple part.

I excluded the request context activation tests until those are in.

17/27 tests are failing

{code}
Tests run: 27, Failures: 17, Errors: 0, Skipped: 0, Time elapsed: 16.639 sec 
<<< FAILURE! - in TestSuite
instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.523 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@4ec88fd9]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@4ec88fd9]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Method 
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@4ec88fd9]
 should have thrown an exception of class java.lang.IllegalStateException

instanceSelectClassThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.072 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@2e2bb4db]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@2e2bb4db]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Method 
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@2e2bb4db]
 should have thrown an exception of class java.lang.IllegalStateException

seContainerThrowsISEWhenAccessingBmAtShutdownContainer(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.074 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@38709d97]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.testng.TestException: 
Method 
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@38709d97]
 should have thrown an exception of class java.lang.IllegalStateException
Caused by: org.testng.TestException: 

Method 
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer()[pri:0,
 
instance:org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest@38709d97]
 should have thrown an exception of class java.lang.IllegalStateException

testAddDecorator(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest) 
 Time elapsed: 0.062 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAddDecorator(BootstrapSEContainerTest.java:244)

testAddInterceptor(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.048 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 

Re: XBean & ShrinkWrap archives

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-07-31 0:45 GMT+02:00 John D. Ament :

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

Re: XBean & ShrinkWrap archives

[John D. Ament]

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

Re: XBean & ShrinkWrap archives

[John D. Ament]

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

Re: XBean & ShrinkWrap archives

[Mark Struberg]

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

[John D. Ament]

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

[Mark Struberg]

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

[Romain Manni-Bucau]

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

[John D. Ament]

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 juil. 2017 22:29, "John D. Ament"  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  >
> > 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  >:
> > > >
> > > > 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

[Romain Manni-Bucau]

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

[John D. Ament]

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

[Mark Struberg]

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

XBean & ShrinkWrap archives

[John D. Ament]

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

[jira] [Commented] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106520#comment-16106520
 ] 

John D. Ament commented on OWB-1206:


Well, the reason being that SE and Arquillian should work together without any 
issue.  Right now it's assuming that the configured scanner is the default 
scanner, which may not be the case.  So it makes sense to move register to the 
base interface and require it to always implement it.

> Enable CDI 2.0 TCK SE Tests
> ---
>
> Key: OWB-1206
> URL: https://issues.apache.org/jira/browse/OWB-1206
> Project: OpenWebBeans
>  Issue Type: Improvement
>Reporter: John D. Ament
> Attachments: OWB_1206.patch
>
>
> The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
> ticket to:
> - Enable the suite
> - Fix whatever tests may fail



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106518#comment-16106518
 ] 

Romain Manni-Bucau commented on OWB-1206:
-

Why modifying singleton service? just for the arquillian setup? Is moving SE 
suite in another execution allowing us to not add this SPI? Worse case we 
ignore tck#arquillian#se and just implement equivalent tests in se module. 
(trying to avoid to pollute the runtime too much due to tcks)

> Enable CDI 2.0 TCK SE Tests
> ---
>
> Key: OWB-1206
> URL: https://issues.apache.org/jira/browse/OWB-1206
> Project: OpenWebBeans
>  Issue Type: Improvement
>Reporter: John D. Ament
> Attachments: OWB_1206.patch
>
>
> The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
> ticket to:
> - Enable the suite
> - Fix whatever tests may fail



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106516#comment-16106516
 ] 

John D. Ament commented on OWB-1206:


Many of the errors seem to originate from xbean, and it's odd because what the 
TCK is doing is mixing arquillian and SeContainer.  

{code}
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:0746a2d5-82fa-4d58-8c31-67e9098d07d2.jar/
at 
org.apache.xbean.finder.archive.ClasspathArchive.archive(ClasspathArchive.java:87)
at 
org.apache.webbeans.corespi.scanner.xbean.CdiArchive.(CdiArchive.java:67)
at 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.initFinder(AbstractMetaDataDiscovery.java:113)
at 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery.scan(AbstractMetaDataDiscovery.java:153)
... 100 more
{code}

This combination seems to be creating archives that xbean can't understand.  

> Enable CDI 2.0 TCK SE Tests
> ---
>
> Key: OWB-1206
> URL: https://issues.apache.org/jira/browse/OWB-1206
> Project: OpenWebBeans
>  Issue Type: Improvement
>Reporter: John D. Ament
> Attachments: OWB_1206.patch
>
>
> The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
> ticket to:
> - Enable the suite
> - Fix whatever tests may fail



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated OWB-1206:
---
Attachment: OWB_1206.patch

The following tests fail after making the attached changes

{code}
instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.043 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.apache.webbeans.exception.WebBeansDeploymentException: 
java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:277)
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:277)

instanceSelectClassThrowsISEWhenAccessedAfterShutdown(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.012 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.apache.webbeans.exception.WebBeansDeploymentException: 
java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:270)
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown(BootstrapSEContainerTest.java:270)

seContainerThrowsISEWhenAccessingBmAtShutdownContainer(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.009 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 
org.apache.webbeans.exception.WebBeansDeploymentException: 
java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer(BootstrapSEContainerTest.java:263)
Caused by: java.lang.UnsupportedOperationException: unsupported archive type: 
archive:d9daa923-3492-425a-ac6a-6cf639aa77b4.jar/
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.initializeAndShutdownContainer(BootstrapSEContainerTest.java:283)
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer(BootstrapSEContainerTest.java:263)

testAddDecorator(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest) 
 Time elapsed: 0.02 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAddDecorator(BootstrapSEContainerTest.java:244)

testAddInterceptor(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.005 sec  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAddInterceptor(BootstrapSEContainerTest.java:227)

testAlternativesInSE(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.014 sec  <<< FAILURE!
java.lang.AssertionError: expected [Circle] but found [Square]
at 
org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest.testAlternativesInSE(BootstrapSEContainerTest.java:138)

testContainerCloseMethodOnNotInitializedContainer(org.jboss.cdi.tck.tests.se.container.BootstrapSEContainerTest)
  Time elapsed: 0.012 sec  <<< FAILURE!
org.testng.TestException: 

Expected exception java.lang.IllegalStateException but got 

Re: do a 2.0.1 release?

[Romain Manni-Bucau]

oops, yes 2.0.1 ;)

Agreed with John for OWB, SE should be more tested before 2.0.1


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-07-30 14:20 GMT+02:00 Mark Struberg :

> Txs, will check it later. Currently doing an upgrade to tomcat8.5 for our
> integration tests.
>
> LieGrue,
> strub
>
>
> > Am 30.07.2017 um 13:39 schrieb John D. Ament :
> >
> > Hi,
> >
> > Looks like there's still a couple of issues open in 2.0.1 [1].  I'm
> > surprised there's no testing for [2], I'm guessing it's ignored in the
> > TCK?  If you can wait until tomorrow I should be able to get a patch
> > together for it, if not go for it.
> >
> > [1]: https://issues.apache.org/jira/projects/OWB/versions/12341073
> > [2]: https://issues.apache.org/jira/browse/OWB-1191
> >
> >
> > On Sun, Jul 30, 2017 at 7:37 AM Mark Struberg  >
> > wrote:
> >
> >> Well, I was thinking about a OWB-2.0.1 release.
> >> And of course then do a MW-2.0.0 or MW-1.1.0 (not sure anymore on what
> we
> >> settled and which is better for MW).
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 30.07.2017 um 12:10 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Hi Mark,
> >>>
> >>> I would include the coming johnzon release and maybe do a 2.0.0 before
> >> the
> >>> 2.0.1 ;)
> >>>
> >>> But overall +1 to release
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | JavaEE Factory
> >>> 
> >>>
> >>> 2017-07-30 10:47 GMT+02:00 Mark Struberg :
> >>>
>  Hi folks!
> 
>  We've fixed a few important bugs in trunk. Should we do a 2.0.1
> release?
>  Could start it in the afternoon.
> 
>  LieGrue,
>  strub
> 
> >>
> >>
>
>

[jira] [Commented] (OWB-1191) implement api for manual request-context handling

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106509#comment-16106509
 ] 

Romain Manni-Bucau commented on OWB-1191:
-

We can include them since we target se actually, was an abuse to exclude them

> implement api for manual request-context handling
> -
>
> Key: OWB-1191
> URL: https://issues.apache.org/jira/browse/OWB-1191
> Project: OpenWebBeans
>  Issue Type: Sub-task
>  Components: Context and Scopes
>Reporter: Gerhard Petracek
> Fix For: 2.0.1
>
> Attachments: OWB_1191.patch
>
>
> new parts:
>  * ActivateRequestContext
>  * RequestContextController



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (OWB-1206) Enable CDI 2.0 TCK SE Tests

[John D. Ament (JIRA)]

John D. Ament created OWB-1206:
--

 Summary: Enable CDI 2.0 TCK SE Tests
 Key: OWB-1206
 URL: https://issues.apache.org/jira/browse/OWB-1206
 Project: OpenWebBeans
  Issue Type: Improvement
Reporter: John D. Ament


The CDI 2.0 TCK tests for Java SE are currently disabled.  This is a holder 
ticket to:

- Enable the suite
- Fix whatever tests may fail



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (OWB-1191) implement api for manual request-context handling

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/OWB-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106496#comment-16106496
 ] 

John D. Ament commented on OWB-1191:


Oh , I see.  OWB's ignoring the SE tests..

{code}





{code}

> implement api for manual request-context handling
> -
>
> Key: OWB-1191
> URL: https://issues.apache.org/jira/browse/OWB-1191
> Project: OpenWebBeans
>  Issue Type: Sub-task
>  Components: Context and Scopes
>Reporter: Gerhard Petracek
> Fix For: 2.0.1
>
> Attachments: OWB_1191.patch
>
>
> new parts:
>  * ActivateRequestContext
>  * RequestContextController



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OWB-1191) implement api for manual request-context handling

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OWB-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated OWB-1191:
---
Attachment: OWB_1191.patch

Here's a patch, untested, but looks logically right.  

I'm not sure yet how to bind an interceptor the same way, but this should at 
least add the built in bean.

> implement api for manual request-context handling
> -
>
> Key: OWB-1191
> URL: https://issues.apache.org/jira/browse/OWB-1191
> Project: OpenWebBeans
>  Issue Type: Sub-task
>  Components: Context and Scopes
>Reporter: Gerhard Petracek
> Fix For: 2.0.1
>
> Attachments: OWB_1191.patch
>
>
> new parts:
>  * ActivateRequestContext
>  * RequestContextController



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: do a 2.0.1 release?

[Mark Struberg]

Txs, will check it later. Currently doing an upgrade to tomcat8.5 for our 
integration tests.

LieGrue,
strub


> Am 30.07.2017 um 13:39 schrieb John D. Ament :
> 
> Hi,
> 
> Looks like there's still a couple of issues open in 2.0.1 [1].  I'm
> surprised there's no testing for [2], I'm guessing it's ignored in the
> TCK?  If you can wait until tomorrow I should be able to get a patch
> together for it, if not go for it.
> 
> [1]: https://issues.apache.org/jira/projects/OWB/versions/12341073
> [2]: https://issues.apache.org/jira/browse/OWB-1191
> 
> 
> On Sun, Jul 30, 2017 at 7:37 AM Mark Struberg 
> wrote:
> 
>> Well, I was thinking about a OWB-2.0.1 release.
>> And of course then do a MW-2.0.0 or MW-1.1.0 (not sure anymore on what we
>> settled and which is better for MW).
>> 
>> LieGrue,
>> strub
>> 
>>> Am 30.07.2017 um 12:10 schrieb Romain Manni-Bucau >> :
>>> 
>>> Hi Mark,
>>> 
>>> I would include the coming johnzon release and maybe do a 2.0.0 before
>> the
>>> 2.0.1 ;)
>>> 
>>> But overall +1 to release
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | JavaEE Factory
>>> 
>>> 
>>> 2017-07-30 10:47 GMT+02:00 Mark Struberg :
>>> 
 Hi folks!
 
 We've fixed a few important bugs in trunk. Should we do a 2.0.1 release?
 Could start it in the afternoon.
 
 LieGrue,
 strub
 
>> 
>> 

Re: do a 2.0.1 release?

[John D. Ament]

Hi,

Looks like there's still a couple of issues open in 2.0.1 [1].  I'm
surprised there's no testing for [2], I'm guessing it's ignored in the
TCK?  If you can wait until tomorrow I should be able to get a patch
together for it, if not go for it.

[1]: https://issues.apache.org/jira/projects/OWB/versions/12341073
[2]: https://issues.apache.org/jira/browse/OWB-1191


On Sun, Jul 30, 2017 at 7:37 AM Mark Struberg 
wrote:

> Well, I was thinking about a OWB-2.0.1 release.
> And of course then do a MW-2.0.0 or MW-1.1.0 (not sure anymore on what we
> settled and which is better for MW).
>
> LieGrue,
> strub
>
> > Am 30.07.2017 um 12:10 schrieb Romain Manni-Bucau  >:
> >
> > Hi Mark,
> >
> > I would include the coming johnzon release and maybe do a 2.0.0 before
> the
> > 2.0.1 ;)
> >
> > But overall +1 to release
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | JavaEE Factory
> > 
> >
> > 2017-07-30 10:47 GMT+02:00 Mark Struberg :
> >
> >> Hi folks!
> >>
> >> We've fixed a few important bugs in trunk. Should we do a 2.0.1 release?
> >> Could start it in the afternoon.
> >>
> >> LieGrue,
> >> strub
> >>
>
>

do a 2.0.1 release?

[Mark Struberg]

Hi folks!

We've fixed a few important bugs in trunk. Should we do a 2.0.1 release?
Could start it in the afternoon.

LieGrue,
strub