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" <[email protected]> a écrit : > On Mon, Aug 14, 2017 at 8:19 AM Romain Manni-Bucau <[email protected]> > wrote: > > > 2017-08-14 13:50 GMT+02:00 John D. Ament <[email protected]>: > > > > > On Mon, Aug 14, 2017 at 1:03 AM Romain Manni-Bucau < > > [email protected]> > > > wrote: > > > > > > > Le 14 août 2017 04:31, "John D. Ament" <[email protected]> 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 > > > > > > > > > >
