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