Another idea: what if we split the Interceptor/DecoratorHandler handling from the NormalScopedBeanInterceptor?
My proposal: 1.) The NormalScopedBeanInterceptorHandler should not derive from the InterceptorHandler anymore, but should form the parent of an own tree (with ApplicationScopedBeanHandler, SessionScopedBeanHandler, ... with caching functionality) 2.) The Bean<T>#create(CreationalContext<T>) should check whether a decorator or interceptor should get applied and then return not only the pure contextual instance, but proxied with the filled InterceptorHandler. We need to think a bit further about how to stack interceptors, and also about methodfilters. wdyt? LieGrue, strub --- Mark Struberg <[email protected]> schrieb am Mi, 17.3.2010: > Von: Mark Struberg <[email protected]> > Betreff: Re: [jira] Created: (OWB-329) Interceptor instances get created each > time the interceptor gets called > An: [email protected] > Datum: Mittwoch, 17. März, 2010 10:44 Uhr > That comes pretty close to what I > thought off. > > There are imo 2 ways to solve this > > a) use the 'old' CreationalContext as you proposed > > b) always create the full interceptor and decorator stack > upfront when the contextual Instance gets created. > > I'm not sure how we could implement a) because there is no > method in javax.enterprise.context.spi.Context for getting > the original CreationalContext of a contextual instance > later. > > LieGrue, > strub > > > --- Gurkan Erdogdu <[email protected]> > schrieb am Mi, 17.3.2010: > > > Von: Gurkan Erdogdu <[email protected]> > > Betreff: Re: [jira] Created: (OWB-329) Interceptor > instances get created each time the interceptor gets > called > > An: [email protected] > > Datum: Mittwoch, 17. März, 2010 09:35 Uhr > > One more thing; > > ----------------------- > > > > Currently in our NormalScopedBeansInterceptorHandler, > we > > use the given > > "CreationalContext" to the constructor. Seems that > this is > > not correct. If > > we have a save instance of bean in AbstractContext, we > have > > to use the save > > CreationalContext instance in the AbstractContext. > > > > Why? > > ----------------- > > > > In a freshly created instance, we save the dependent > > objects of the bean in > > the CreaitonalContext and save it into our context > > instance. In later > > operations, if we use given CreationalContext instead > of > > using saved > > version, we loose the dependent instances of bean. > > Therefore below logic > > does not work as expected. > > > > For example; > > ----------------------- > > We have an @ApplicatioScoped bean and client calls > > manager.getReference(bean,type,creational) and we > return a > > proxy. Client > > calls method on a proxy object, then we create bean > > instance and all of its > > interceptor instances. We put all of its interceptor > > instances into > > CreationalContextImpl.addDependent and mark them as > > interceptor. Now, we > > have a "bean instance" and "its creational context" > in > > AbstractContext. > > > > Client again calls manager.getReference(bean,type,new > > creational). If we do > > not use saved creational context, whenever we want to > get > > interceptors of > > the bean, it returns an empty set because "new > creational" > > does not contain > > it. And container creates a new interceptor instance > again > > that we do not > > want! > > > > But those are not applied for DependentScoped beans > because > > they are created > > an each time client calls manager.getReference() and > it > > creates a new > > instance of interceptor. > > > > Thanks; > > > > --Gurkan > > > > 2010/3/17 Gurkan Erdogdu <[email protected]> > > > > > Hello; > > > > > > I was thinking about to update our interceptor > logic > > but not found time. > > > Indeed, our interceptor logic is not correct. > > Currently, we setup > > > InterceptorStack for bean but this interceptor > stack > > is shared by all > > > instances of this bean, this is not correct. For > > example, @RequestScoped > > > beans may override each of thier interceptor > > instances, because > > > InterceptorData uses interceptor instance and > > InterceptorData is shared by > > > all beans (same InterceptorStack that contains > > InterceptorData) > > > > > > We have to separate interceptor instance from > > InterceptorStack(contains > > > InterceptorData). So, mapping should be > > > - Bean --> InterceptorStack (also remove > "Object > > interceptorInstance" from > > > InterceptorData) > > > - Bean Instance --> Interceptor Instance > > > > > > We can use CreationalContextImpl to save bean > > interceptor instances. We can > > > add another field into DependentCreationalContext > to > > mark dependent instance > > > as "interceptor". After that we can get > interceptor > > instance from there > > > whenever a intercepted method is called. > > > > > > We have to do similar things for decorator > instances. > > Currently, we call > > > WebBeansDecoratorConfig#getDecoratorStack for > every > > invocation and it > > > creates a new instance of decorators. > > > > > > Thanks; > > > > > > --Gurkan > > > > > > > > > 2010/3/17 Mark Struberg (JIRA) <[email protected]> > > > > > > Interceptor instances get created each time the > > interceptor gets called > > >> > > > ----------------------------------------------------------------------- > > >> > > >> > > Key: OWB-329 > > >> > > URL: https://issues.apache.org/jira/browse/OWB-329 > > >> > > Project: OpenWebBeans > > >> Issue Type: Bug > > >> Components: > > Interceptor and Decorators > > >> Affects Versions: M4 > > >> Reporter: > > Mark Struberg > > >> Assignee: > > Mark Struberg > > >> Priority: > > Critical > > >> > > Fix For: 1.0.0 > > >> > > >> > > >> Interceptors are defined as being @Dependent > > scoped. Thus, for one > > >> @ApplicationScoped contextual instance, only > one > > interceptor instance of a > > >> certain type must exist. But we currently > create a > > new instance for each and > > >> every method invocation which is > intercepted. > > >> > > >> This is not only terribly slow, but also > doesn't > > work as expected from a > > >> portable perspective. > > >> > > >> -- > > >> This message is automatically generated by > JIRA. > > >> - > > >> You can reply to this email to add a comment > to > > the issue online. > > >> > > >> > > > > > > > > > -- > > > Gurkan Erdogdu > > > http://gurkanerdogdu.blogspot.com > > > > > > > > > > > -- > > Gurkan Erdogdu > > http://gurkanerdogdu.blogspot.com > > > > __________________________________________________ > Do You Yahoo!? > Sie sind Spam leid? Yahoo! Mail verfügt über einen > herausragenden Schutz gegen Massenmails. > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
