Dependent scoped beans is yet another area where the new logic is simply better. There is no difference between @DependentScoped beans and @NormalScoped beans anymore. There is also no need to handle DependentScoped beans different in that respect. They simply don't get the NormalScopedProxy applied at the injection point, and that's all!
The old logic had a bug where dependent->dependent beans didn't get intercepted btw. There is also no need to handle something special for @RequestScoped beans. I don't see this point and also no need to code special things for different scopes in general! LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Mi, 24.3.2010: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: attention - danger zone ;) > An: [email protected] > Datum: Mittwoch, 24. März, 2010 12:27 Uhr > >>ad 2.) the logic is really > simple: If a bean defines interceptors or > decorators, we create a contextual instance which includes > >>this > functionality. We do this by creating a proxy and 1:1 > delegating to exactly > the one contextual instance it serves. So for >>each > contextual instance > which needs to get intercepted/decorated, we create a > single proxy to serve > this purpose > > Actually this is more complex. This semantic can not be > applied for > RequestScoped instances and you have to write new > class(subclass) for each > different scoped beans. Also you have to think about > DependentScoped beans. > Current implenetation just uses InterceptorHandler for all > kind of beans. > > 2010/3/24 Mark Struberg <[email protected]> > > > hi sven! > > > > yes and no :) > > > > ad 1.) yes, I aim for separating those concerns into 2 > different > > MethodHandlers which will get manifested in 2 proxy > objects. > > > > ad 2.) the logic is really simple: If a bean defines > interceptors or > > decorators, we create a contextual instance which > includes this > > functionality. We do this by creating a proxy and 1:1 > delegating to exactly > > the one contextual instance it serves. So for each > contextual instance which > > needs to get intercepted/decorated, we create a single > proxy to serve this > > purpose > > > > For all @NormalScoped beans, I'll create a > NormalScopedBeanProxy which only > > serves to resolve the correct contextual instance > (with any interception > > already applied) and delegates all method invocations > to this underlying > > contextual instance. > > > > So while the InterceptorProxy instance is 1:1 bound to > the contextual > > instance, the NormalScopedBeanProxy is 1:1 bound to > the injection point. But > > there is no 1:1 relation between those 2 proxies but a > n:m. And that is what > > made the old code so complicated to read, because all > the resolving needed > > to switch dynamically. > > > > ad 3.) Yes, if the context is a passivating one, then > the contextual > > instance (including all it's interceptors/decorators) > will get serialized to > > that passivation storage. This is now exactly as it is > defined in the spec! > > > > ad 4.) exactly! > > > > LieGrue, > > strub > > > > > > --- Sven Linstaedt <[email protected]> > schrieb am Di, > > 23.3.2010: > > > > > Von: Sven Linstaedt <[email protected]> > > > Betreff: Re: attention - danger zone ;) > > > An: [email protected] > > > Datum: Dienstag, 23. März, 2010 23:17 Uhr > > > Hi Mark, > > > > > > just for my personal understanding: The proposed > changes > > > imply: > > > > > > 1. Introducing two seperate MethodHandler. One > for > > > resolving NormalScope > > > beans to the actual instance. Another one for > applying the > > > interception/decoration stack. > > > > > > 2. As only one MethodHandler can be attached to > proxy class > > > instances, for > > > dependent scoped beans the > interception/decoration handler > > > is attached. For > > > normal scope instances the resolving handler is > attached. > > > > > > 3. The interception/decoration MethodHandler > including the > > > actual > > > interceptor/decorator instances is part of the > bean state > > > (?), so it is > > > serialized to a normal scope along with the bean > instance. > > > > > > 4. This implies the scope receives not the > concrete bean > > > instance, but > > > rather the proxy class instance with attached > > > MethodHandler, which in turn > > > contains of the bean instance and > interceptor/decorator > > > instances? > > > > > > > > > br, Sven > > > > > > > > > 2010/3/23 Mark Struberg <[email protected]> > > > > > > > The current > NormalScopedBeanInterceptorHandler is a > > > subclass of the > > > > InterceptorHandler. > > > > > > > > But while the InterceptorHandler is fixed > 1:1 to a > > > contextual instance, the > > > > proxy we need to handle the NormalScoped > behaviour is > > > different for each and > > > > every injection point. There is currently a > lot code > > > to work around this > > > > logical separation, but I consider this to > be what it > > > is - a workaround. See > > > > my comments on OWB-329. Maybe I was not > clear enough > > > and should elaborate > > > > further? > > > > > > > > txs and LieGrue, > > > > strub > > > > > > > > --- Gurkan Erdogdu <[email protected]> > > > schrieb am Di, 23.3.2010: > > > > > > > > > Von: Gurkan Erdogdu <[email protected]> > > > > > Betreff: Re: attention - danger zone > ;) > > > > > An: [email protected] > > > > > Datum: Dienstag, 23. März, 2010 19:51 > Uhr > > > > > >>>I'm currently refactoring > > > > > the decorator / interceptor stuff by > > > > > splitting the Interceptor and > Decorator > > > MethodHandlers from > > > > > the > > > > > > >>>NormalScopedBeanMethodHandler. > > > > > Why? Interceptor/Decorator is handled > in the > > > abstract class > > > > > InterceptorHandler not in > > > NormalScopedBeanMethodHandler. > > > > > > > > > > What is the problem with current > approach? > > > Currently > > > > > InterceptorHandler performs > interceptor/decorator > > > stack for > > > > > bean just one case. > > > > > > > > > > Thanks; > > > > > > > > > > --Gurkan > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > From: Mark Struberg <[email protected]> > > > > > To: [email protected] > > > > > Sent: Tue, March 23, 2010 8:09:49 PM > > > > > Subject: attention - danger zone ;) > > > > > > > > > > Hi! > > > > > > > > > > I'm currently refactoring the decorator > / > > > interceptor stuff > > > > > by splitting the Interceptor and > Decorator > > > MethodHandlers > > > > > from the > NormalScopedBeanMethodHandler. > > > > > > > > > > This will also allow implementing those > parts as > > > pure > > > > > subclasses later. > > > > > > > > > > I'm back to only 2 broken tests and my > real world > > > app is > > > > > running again. > > > > > > > > > > Please do not checkin big changes into > SVN in > > > > > webbeans-impl. > > > > > > > > > > txs and LieGrue, > > > > > strub > > > > > > > > > > > > > > __________________________________________________ > > > > > 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 > > > > > > -- > 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
