On Mon, Aug 14, 2017 at 8:19 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 2017-08-14 13:50 GMT+02:00 John D. Ament <johndam...@apache.org>: > > > On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > Le 14 août 2017 04:31, "John D. Ament" <john.d.am...@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 > > > > > >
