I will dig into details today. Discuss it on the irc. But it does not so much hard to do without breaking something :)
Thanks; 2010/3/17 Mark Struberg <[email protected]> > 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 > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
