Sure :)
________________________________ From: Mark Struberg <[email protected]> To: [email protected] Sent: Wed, March 17, 2010 5:54:47 PM Subject: Re: [jira] Created: (OWB-329) Interceptor instances get created each time the interceptor gets called Gurkan, I'll copy our chat over to the Jira, otherwise no one could follow our decisions later ;) 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 16:51 Uhr > lol oki, so now we have two impls of > that :D > I'll wait with my commit, looking forward to check your > version ;) > > 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 16:48 Uhr > > I have implemented it. I will commit > > this afternoon :) > > > > > > Thanks; > > > > --Gurkan > > > > > > > > > > ________________________________ > > From: Mark Struberg <[email protected]> > > To: [email protected] > > Sent: Wed, March 17, 2010 5:37:33 PM > > Subject: Re: [jira] Created: (OWB-329) Interceptor > > instances get created each time the interceptor > gets > > called > > > > 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 > > > > > > > > > > > ___________________________________________________________________ > > Yahoo! Türkiye açıldı! http://yahoo.com.tr > > İnternet üzerindeki en iyi içeriği Yahoo! > Türkiye > > sizlere sunuyor! > > __________________________________________________ > 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 ___________________________________________________________________ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
