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...@gmail.com> on 2017/08/14 02:31:20 UTC
Update on SE support
Hey guys
Good news on the SE support front. Looks like there were two features just
missing outright in OWB 2 from CDI 2.0.
- Support for a config property javax.enterprise.inject.implicit.scan which
works the opposite of org.apache.webbeans.scanBeansXmlOnly
- Firing BeforeDestroyed when destroying a context
After getting those done, and ignoring issues with manual request context
activation, we're down to only a few failing TCK tests
Failed tests:
BootstrapSEContainerTest.instanceSelectAnnotationThrowsISEWhenAccessedAfterShutdown
» Test
BootstrapSEContainerTest.instanceSelectClassThrowsISEWhenAccessedAfterShutdown
» Test
BootstrapSEContainerTest.seContainerThrowsISEWhenAccessingBmAtShutdownContainer
» Test
BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
expected [true] but found [false]
BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
expected [true] but found [false]
BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
expected [Circle] but found [Square]
BootstrapSEContainerTest.testContainerCloseMethodOnNotInitializedContainer
» Test
BootstrapSEContainerTest>Arquillian.run:164->testInvocationOfInitializedMethodReturnsNewSeContainerInstance:103
» WebBeansDeployment
BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253 »
IllegalArgument
BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114 »
IllegalArgument
InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown »
Test ...
CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77 »
UnsatisfiedResolution
RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPostConstructCallback:72
null
CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
expected [null] but found [org.apache.webbeans.container.OwbCDI@7755e503]
Most of them are caused by OWB not destroying contextual references when
the container shuts down, its almost like OWB never actually stops when you
call close on the SE Container.
The two interesting ones I dug into are CustomCDIProviderTest and
RequestContextTest.
For the custom CDI provider, it's actually a bug in the geronimo spec, its
treating a null returned from the CDIProvider as being not set, but the TCK
is implying that its fine, and instead should just be null because the
provider was set.
The Request context one is a bit trickier. It looks like OWB's behavior is
to start all contexts where the SE container behavior is to only start an
application context. There's already StandaloneLifeCycle which I think we
should leave alone, and instead create a special SELifeCycle in the se
module to better align to the spec's requirements. Thoughts?
I'll keep hacking away. I did start a branch on github
https://github.com/johnament/openwebbeans/tree/se-updates .
John
Re: Update on SE support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
If we change it we change what request scope is making impossible to move
to the spec OOTB - and btw this is how it behaves in any app pre cdi 2.0
and webapp evzn in cdi 2. Im really in favor of a flag to support both
without having to know any internal/classname and enable users to rely on
it for testing etc without breaking their code.
Wdyt?
Le 15 août 2017 02:06, "John D. Ament" <jo...@apache.org> a écrit :
> On Mon, Aug 14, 2017 at 8:19 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 2017-08-14 13:50 GMT+02:00 John D. Ament <jo...@apache.org>:
> >
> > > On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Le 14 août 2017 04:31, "John D. Ament" <jo...@gmail.com> a
> > écrit
> > > :
> > > >
> > > > Hey guys
> > > >
> > > > Good news on the SE support front. Looks like there were two
> features
> > > just
> > > > missing outright in OWB 2 from CDI 2.0.
> > > >
> > > > - Support for a config property javax.enterprise.inject.
> implicit.scan
> > > which
> > > > works the opposite of org.apache.webbeans.scanBeansXmlOnly
> > > > - Firing BeforeDestroyed when destroying a context
> > > >
> > > > After getting those done, and ignoring issues with manual request
> > context
> > > > activation, we're down to only a few failing TCK tests
> > > >
> > > > Failed tests:
> > > >
> > > > BootstrapSEContainerTest.instanceSelectAnnotationThrows
> > > > ISEWhenAccessedAfterShutdown
> > > > » Test
> > > >
> > > > BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
> > > > enAccessedAfterShutdown
> > > > » Test
> > > >
> > > > BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
> > > > ingBmAtShutdownContainer
> > > > » Test
> > > > BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
> > > > expected [true] but found [false]
> > > > BootstrapSEContainerTest>Arquillian.run:164->
> testAddInterceptor:227
> > > > expected [true] but found [false]
> > > > BootstrapSEContainerTest>Arquillian.run:164->
> testAlternativesInSE:138
> > > > expected [Circle] but found [Square]
> > > >
> > > > BootstrapSEContainerTest.testContainerCloseMethodOnNotI
> > > nitializedContainer
> > > > » Test
> > > >
> > > > BootstrapSEContainerTest>Arquillian.run:164->
> > > testInvocationOfInitializedMet
> > > > hodReturnsNewSeContainerInstance:103
> > > > » WebBeansDeployment
> > > >
> > BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253
> > > »
> > > > IllegalArgument
> > > > BootstrapSEContainerTest>Arquillian.run:164->
> testSyntheticArchive:114
> > > »
> > > > IllegalArgument
> > > >
> > InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown
> > > »
> > > > Test ...
> > > > CustomClassLoaderSETest>Arquillian.run:164->
> testCustomClassLoader:77
> > »
> > > > UnsatisfiedResolution
> > > >
> > > > RequestContextTest>Arquillian.run:164->
> requestContextIsActiveDuringPo
> > > > stConstructCallback:72
> > > > null
> > > > CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
> > > > expected [null] but found
> > [org.apache.webbeans.container.OwbCDI@7755e503
> > > ]
> > > >
> > > > Most of them are caused by OWB not destroying contextual references
> > when
> > > > the container shuts down, its almost like OWB never actually stops
> when
> > > you
> > > > call close on the SE Container.
> > > >
> > > > The two interesting ones I dug into are CustomCDIProviderTest and
> > > > RequestContextTest.
> > > >
> > > > For the custom CDI provider, it's actually a bug in the geronimo
> spec,
> > > its
> > > > treating a null returned from the CDIProvider as being not set, but
> the
> > > TCK
> > > > is implying that its fine, and instead should just be null because
> the
> > > > provider was set.
> > > >
> > > > The Request context one is a bit trickier. It looks like OWB's
> > behavior
> > > is
> > > > to start all contexts where the SE container behavior is to only
> start
> > an
> > > > application context. There's already StandaloneLifeCycle which I
> think
> > > we
> > > > should leave alone, and instead create a special SELifeCycle in the
> se
> > > > module to better align to the spec's requirements. Thoughts?
> > > >
> > > >
> > > > Still thinking but what about keeping our defaults based on past
> usage
> > > > experience and having properties to tune it?
> > > >
> > > >
> > > >
> > > Romain, I'm not sure if your response is to the whole email or this
> last
> > > section.
> > >
> >
> > last section only, other parts was clear and didnt ask much comment from
> me
> > ;)
> >
> >
> > >
> > > If it's about this last section, that's why I'm thinking to create a
> new
> > > lifecycle. This way by default you get the SELifeCycle which operates
> > > based on the spec, but you can easily override it in
> > > openwebbeans.properties to use the StandaloneLifeCycle to make a bit
> more
> > > sense (however, when we talked about how to activate the other contexts
> > in
> > > the EG there was a lot of confusion and problems uncovered, e.g. what
> is
> > > the underlying bean store for session scoped across multiple "requests"
> > and
> > > how do I get that same store each time?)
> > >
> > > We could even name it "JSR365SELifeCycle" to make it extremely clear
> that
> > > this is in to satisfy the requirements of the JSR only.
> > >
> >
> > Issue is not the name but the usage. Most of the time you will need it I
> > think so do we want to break users going to a standard? The spec doesn't
> > prevent to support other scopes as well so if we have flags to deactivate
> > them then we are good.
> >
>
> No, that's the thing. The TCK assertion is that request context in SE is
> only active during post construct, not during arbitrary method
> invocations. This test fails because request context is active during both
> the post construct and the method invocation.
>
> Granted, I'm worried that OWB is relying on this behavior to start request
> context for post construct method invocations.
>
>
> >
> > After do we do it in 2 lifecycles or a single one is another topic but I
> > don't have a strong preference.
> >
> >
> > >
> > >
> > > >
> > > > I'll keep hacking away. I did start a branch on github
> > > > https://github.com/johnament/openwebbeans/tree/se-updates .
> > > >
> > > > John
> > > >
> > >
> >
>
Re: Update on SE support
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Aug 14, 2017 at 8:19 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 2017-08-14 13:50 GMT+02:00 John D. Ament <jo...@apache.org>:
>
> > On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Le 14 août 2017 04:31, "John D. Ament" <jo...@gmail.com> a
> écrit
> > :
> > >
> > > Hey guys
> > >
> > > Good news on the SE support front. Looks like there were two features
> > just
> > > missing outright in OWB 2 from CDI 2.0.
> > >
> > > - Support for a config property javax.enterprise.inject.implicit.scan
> > which
> > > works the opposite of org.apache.webbeans.scanBeansXmlOnly
> > > - Firing BeforeDestroyed when destroying a context
> > >
> > > After getting those done, and ignoring issues with manual request
> context
> > > activation, we're down to only a few failing TCK tests
> > >
> > > Failed tests:
> > >
> > > BootstrapSEContainerTest.instanceSelectAnnotationThrows
> > > ISEWhenAccessedAfterShutdown
> > > » Test
> > >
> > > BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
> > > enAccessedAfterShutdown
> > > » Test
> > >
> > > BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
> > > ingBmAtShutdownContainer
> > > » Test
> > > BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
> > > expected [true] but found [false]
> > > BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
> > > expected [true] but found [false]
> > > BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
> > > expected [Circle] but found [Square]
> > >
> > > BootstrapSEContainerTest.testContainerCloseMethodOnNotI
> > nitializedContainer
> > > » Test
> > >
> > > BootstrapSEContainerTest>Arquillian.run:164->
> > testInvocationOfInitializedMet
> > > hodReturnsNewSeContainerInstance:103
> > > » WebBeansDeployment
> > >
> BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253
> > »
> > > IllegalArgument
> > > BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114
> > »
> > > IllegalArgument
> > >
> InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown
> > »
> > > Test ...
> > > CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77
> »
> > > UnsatisfiedResolution
> > >
> > > RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPo
> > > stConstructCallback:72
> > > null
> > > CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
> > > expected [null] but found
> [org.apache.webbeans.container.OwbCDI@7755e503
> > ]
> > >
> > > Most of them are caused by OWB not destroying contextual references
> when
> > > the container shuts down, its almost like OWB never actually stops when
> > you
> > > call close on the SE Container.
> > >
> > > The two interesting ones I dug into are CustomCDIProviderTest and
> > > RequestContextTest.
> > >
> > > For the custom CDI provider, it's actually a bug in the geronimo spec,
> > its
> > > treating a null returned from the CDIProvider as being not set, but the
> > TCK
> > > is implying that its fine, and instead should just be null because the
> > > provider was set.
> > >
> > > The Request context one is a bit trickier. It looks like OWB's
> behavior
> > is
> > > to start all contexts where the SE container behavior is to only start
> an
> > > application context. There's already StandaloneLifeCycle which I think
> > we
> > > should leave alone, and instead create a special SELifeCycle in the se
> > > module to better align to the spec's requirements. Thoughts?
> > >
> > >
> > > Still thinking but what about keeping our defaults based on past usage
> > > experience and having properties to tune it?
> > >
> > >
> > >
> > Romain, I'm not sure if your response is to the whole email or this last
> > section.
> >
>
> last section only, other parts was clear and didnt ask much comment from me
> ;)
>
>
> >
> > If it's about this last section, that's why I'm thinking to create a new
> > lifecycle. This way by default you get the SELifeCycle which operates
> > based on the spec, but you can easily override it in
> > openwebbeans.properties to use the StandaloneLifeCycle to make a bit more
> > sense (however, when we talked about how to activate the other contexts
> in
> > the EG there was a lot of confusion and problems uncovered, e.g. what is
> > the underlying bean store for session scoped across multiple "requests"
> and
> > how do I get that same store each time?)
> >
> > We could even name it "JSR365SELifeCycle" to make it extremely clear that
> > this is in to satisfy the requirements of the JSR only.
> >
>
> Issue is not the name but the usage. Most of the time you will need it I
> think so do we want to break users going to a standard? The spec doesn't
> prevent to support other scopes as well so if we have flags to deactivate
> them then we are good.
>
No, that's the thing. The TCK assertion is that request context in SE is
only active during post construct, not during arbitrary method
invocations. This test fails because request context is active during both
the post construct and the method invocation.
Granted, I'm worried that OWB is relying on this behavior to start request
context for post construct method invocations.
>
> After do we do it in 2 lifecycles or a single one is another topic but I
> don't have a strong preference.
>
>
> >
> >
> > >
> > > I'll keep hacking away. I did start a branch on github
> > > https://github.com/johnament/openwebbeans/tree/se-updates .
> > >
> > > John
> > >
> >
>
Re: Update on SE support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2017-08-14 13:50 GMT+02:00 John D. Ament <jo...@apache.org>:
> On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le 14 août 2017 04:31, "John D. Ament" <jo...@gmail.com> a écrit
> :
> >
> > Hey guys
> >
> > Good news on the SE support front. Looks like there were two features
> just
> > missing outright in OWB 2 from CDI 2.0.
> >
> > - Support for a config property javax.enterprise.inject.implicit.scan
> which
> > works the opposite of org.apache.webbeans.scanBeansXmlOnly
> > - Firing BeforeDestroyed when destroying a context
> >
> > After getting those done, and ignoring issues with manual request context
> > activation, we're down to only a few failing TCK tests
> >
> > Failed tests:
> >
> > BootstrapSEContainerTest.instanceSelectAnnotationThrows
> > ISEWhenAccessedAfterShutdown
> > » Test
> >
> > BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
> > enAccessedAfterShutdown
> > » Test
> >
> > BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
> > ingBmAtShutdownContainer
> > » Test
> > BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
> > expected [true] but found [false]
> > BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
> > expected [true] but found [false]
> > BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
> > expected [Circle] but found [Square]
> >
> > BootstrapSEContainerTest.testContainerCloseMethodOnNotI
> nitializedContainer
> > » Test
> >
> > BootstrapSEContainerTest>Arquillian.run:164->
> testInvocationOfInitializedMet
> > hodReturnsNewSeContainerInstance:103
> > » WebBeansDeployment
> > BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253
> »
> > IllegalArgument
> > BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114
> »
> > IllegalArgument
> > InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown
> »
> > Test ...
> > CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77 »
> > UnsatisfiedResolution
> >
> > RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPo
> > stConstructCallback:72
> > null
> > CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
> > expected [null] but found [org.apache.webbeans.container.OwbCDI@7755e503
> ]
> >
> > Most of them are caused by OWB not destroying contextual references when
> > the container shuts down, its almost like OWB never actually stops when
> you
> > call close on the SE Container.
> >
> > The two interesting ones I dug into are CustomCDIProviderTest and
> > RequestContextTest.
> >
> > For the custom CDI provider, it's actually a bug in the geronimo spec,
> its
> > treating a null returned from the CDIProvider as being not set, but the
> TCK
> > is implying that its fine, and instead should just be null because the
> > provider was set.
> >
> > The Request context one is a bit trickier. It looks like OWB's behavior
> is
> > to start all contexts where the SE container behavior is to only start an
> > application context. There's already StandaloneLifeCycle which I think
> we
> > should leave alone, and instead create a special SELifeCycle in the se
> > module to better align to the spec's requirements. Thoughts?
> >
> >
> > Still thinking but what about keeping our defaults based on past usage
> > experience and having properties to tune it?
> >
> >
> >
> Romain, I'm not sure if your response is to the whole email or this last
> section.
>
last section only, other parts was clear and didnt ask much comment from me
;)
>
> If it's about this last section, that's why I'm thinking to create a new
> lifecycle. This way by default you get the SELifeCycle which operates
> based on the spec, but you can easily override it in
> openwebbeans.properties to use the StandaloneLifeCycle to make a bit more
> sense (however, when we talked about how to activate the other contexts in
> the EG there was a lot of confusion and problems uncovered, e.g. what is
> the underlying bean store for session scoped across multiple "requests" and
> how do I get that same store each time?)
>
> We could even name it "JSR365SELifeCycle" to make it extremely clear that
> this is in to satisfy the requirements of the JSR only.
>
Issue is not the name but the usage. Most of the time you will need it I
think so do we want to break users going to a standard? The spec doesn't
prevent to support other scopes as well so if we have flags to deactivate
them then we are good.
After do we do it in 2 lifecycles or a single one is another topic but I
don't have a strong preference.
>
>
> >
> > I'll keep hacking away. I did start a branch on github
> > https://github.com/johnament/openwebbeans/tree/se-updates .
> >
> > John
> >
>
Re: Update on SE support
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le 14 août 2017 04:31, "John D. Ament" <jo...@gmail.com> a écrit :
>
> Hey guys
>
> Good news on the SE support front. Looks like there were two features just
> missing outright in OWB 2 from CDI 2.0.
>
> - Support for a config property javax.enterprise.inject.implicit.scan which
> works the opposite of org.apache.webbeans.scanBeansXmlOnly
> - Firing BeforeDestroyed when destroying a context
>
> After getting those done, and ignoring issues with manual request context
> activation, we're down to only a few failing TCK tests
>
> Failed tests:
>
> BootstrapSEContainerTest.instanceSelectAnnotationThrows
> ISEWhenAccessedAfterShutdown
> » Test
>
> BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
> enAccessedAfterShutdown
> » Test
>
> BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
> ingBmAtShutdownContainer
> » Test
> BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
> expected [true] but found [false]
> BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
> expected [true] but found [false]
> BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
> expected [Circle] but found [Square]
>
> BootstrapSEContainerTest.testContainerCloseMethodOnNotInitializedContainer
> » Test
>
> BootstrapSEContainerTest>Arquillian.run:164->testInvocationOfInitializedMet
> hodReturnsNewSeContainerInstance:103
> » WebBeansDeployment
> BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253 »
> IllegalArgument
> BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114 »
> IllegalArgument
> InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown »
> Test ...
> CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77 »
> UnsatisfiedResolution
>
> RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPo
> stConstructCallback:72
> null
> CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
> expected [null] but found [org.apache.webbeans.container.OwbCDI@7755e503]
>
> Most of them are caused by OWB not destroying contextual references when
> the container shuts down, its almost like OWB never actually stops when you
> call close on the SE Container.
>
> The two interesting ones I dug into are CustomCDIProviderTest and
> RequestContextTest.
>
> For the custom CDI provider, it's actually a bug in the geronimo spec, its
> treating a null returned from the CDIProvider as being not set, but the TCK
> is implying that its fine, and instead should just be null because the
> provider was set.
>
> The Request context one is a bit trickier. It looks like OWB's behavior is
> to start all contexts where the SE container behavior is to only start an
> application context. There's already StandaloneLifeCycle which I think we
> should leave alone, and instead create a special SELifeCycle in the se
> module to better align to the spec's requirements. Thoughts?
>
>
> Still thinking but what about keeping our defaults based on past usage
> experience and having properties to tune it?
>
>
>
Romain, I'm not sure if your response is to the whole email or this last
section.
If it's about this last section, that's why I'm thinking to create a new
lifecycle. This way by default you get the SELifeCycle which operates
based on the spec, but you can easily override it in
openwebbeans.properties to use the StandaloneLifeCycle to make a bit more
sense (however, when we talked about how to activate the other contexts in
the EG there was a lot of confusion and problems uncovered, e.g. what is
the underlying bean store for session scoped across multiple "requests" and
how do I get that same store each time?)
We could even name it "JSR365SELifeCycle" to make it extremely clear that
this is in to satisfy the requirements of the JSR only.
>
> I'll keep hacking away. I did start a branch on github
> https://github.com/johnament/openwebbeans/tree/se-updates .
>
> John
>
Re: Update on SE support
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 14 août 2017 04:31, "John D. Ament" <jo...@gmail.com> a écrit :
Hey guys
Good news on the SE support front. Looks like there were two features just
missing outright in OWB 2 from CDI 2.0.
- Support for a config property javax.enterprise.inject.implicit.scan which
works the opposite of org.apache.webbeans.scanBeansXmlOnly
- Firing BeforeDestroyed when destroying a context
After getting those done, and ignoring issues with manual request context
activation, we're down to only a few failing TCK tests
Failed tests:
BootstrapSEContainerTest.instanceSelectAnnotationThrows
ISEWhenAccessedAfterShutdown
» Test
BootstrapSEContainerTest.instanceSelectClassThrowsISEWh
enAccessedAfterShutdown
» Test
BootstrapSEContainerTest.seContainerThrowsISEWhenAccess
ingBmAtShutdownContainer
» Test
BootstrapSEContainerTest>Arquillian.run:164->testAddDecorator:244
expected [true] but found [false]
BootstrapSEContainerTest>Arquillian.run:164->testAddInterceptor:227
expected [true] but found [false]
BootstrapSEContainerTest>Arquillian.run:164->testAlternativesInSE:138
expected [Circle] but found [Square]
BootstrapSEContainerTest.testContainerCloseMethodOnNotInitializedContainer
» Test
BootstrapSEContainerTest>Arquillian.run:164->testInvocationOfInitializedMet
hodReturnsNewSeContainerInstance:103
» WebBeansDeployment
BootstrapSEContainerTest>Arquillian.run:164->testSeContainerLookup:253 »
IllegalArgument
BootstrapSEContainerTest>Arquillian.run:164->testSyntheticArchive:114 »
IllegalArgument
InvalidContextualReferenceTest.testReferenceUsedAfterContainerShutdown »
Test ...
CustomClassLoaderSETest>Arquillian.run:164->testCustomClassLoader:77 »
UnsatisfiedResolution
RequestContextTest>Arquillian.run:164->requestContextIsActiveDuringPo
stConstructCallback:72
null
CustomCDIProviderTest>Arquillian.run:164->testCustomCDIProvider:53
expected [null] but found [org.apache.webbeans.container.OwbCDI@7755e503]
Most of them are caused by OWB not destroying contextual references when
the container shuts down, its almost like OWB never actually stops when you
call close on the SE Container.
The two interesting ones I dug into are CustomCDIProviderTest and
RequestContextTest.
For the custom CDI provider, it's actually a bug in the geronimo spec, its
treating a null returned from the CDIProvider as being not set, but the TCK
is implying that its fine, and instead should just be null because the
provider was set.
The Request context one is a bit trickier. It looks like OWB's behavior is
to start all contexts where the SE container behavior is to only start an
application context. There's already StandaloneLifeCycle which I think we
should leave alone, and instead create a special SELifeCycle in the se
module to better align to the spec's requirements. Thoughts?
Still thinking but what about keeping our defaults based on past usage
experience and having properties to tune it?
I'll keep hacking away. I did start a branch on github
https://github.com/johnament/openwebbeans/tree/se-updates .
John