Hi! I now looked at it the last few hours, and I have a pretty good gut feeling that we could split our problem in 2 working tasks.
1st task is to separate the proxies for the NormalScoped beans from the proxies we need for implementing interceptor and decorator logic. 2nd task would be to fix the interceptor and decorators itself. I will now try to do the 1st part by cutting the logic from the InterceptorHandler 1:1 and apply it as separate proxy to form the effective contextual instance to store inside the Context. Any NormalScopedBeanProxy will get applied on top of it and has a completely different logic on it's own. Evaluating the interceptor/decorator stack will only be needed once per contextual instance (could even get further tuned to once per Bean<T> later) and stored in the InterceptorDecoratorMethodHandler. I will not change the logic of the interceptor handling currently, but will only move it into this own proxy! 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 14:27 Uhr > 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 > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
