Hello, DependentScoped and NormalScoped beans are different semantics. You can inject @DependentScoped beans into other Java EE components, for example Servlets, Filters, Tags, MDBs etc. And main point of introducing a CretionalContext into specification is all about this type of injection into non-contextual beans.
Lifecyle of the NormalScopedBeans are under the container but this is not the same for Dependents. Therefore it is under responsibility of the clients(non-contextual beans) to destroy dependent beans they have. But NormalScoped beans are destroyed by the container and their dependents are also destroyed by the container whenever its context ends. You have to read spec. completely in a Java EE model not just for web things. I have written those areas carefully and well-tested. Therefore each normal scoped bean has CreationalContext to save important things that has to be carried with it. After destroying it, container destroys creational contexts of them and their dependent beans and those dependents creational contexts. Also dependent beans have CreationalContexts for destroying it with container or non-contextual beans. For example, you can look at OWBInjector class. For example each Servlet has an OWBInjector to inject its dependencies.Whenever servlet destroyed by the container, their dependents are also destroyed by the OWBInjector#destroy method. Also, dependent beans has a different lifecycle. In current code base, there is no proxy for it. If you change something in implementation without thinking about global changes, then we get into stuck. I know that I am the sole person knowing every nifty details but as you have already seen I have been trying to explain all of the code internals to you. One point I want to share is that, it is not easy to implement those concepts in couple of days. It takes lots of time and appreciate it if you look at when this project is started. I think that we have reached a very good point because of lots of TCK (even all) has passed after long nights. Therefore it takes responsibility to commit something that changes things completely. But I do not say that or else imply that I am the owner and all of my code is correct. Code has owned by the Apache community and it needs lots of update. My main point is that you may not change something if it does not work for your environment/project. Anyway, those are just my 2 cents! I think enough discussion about interceptors/decorators or creational context and hash maps :):) Thanks; --Gurkan ________________________________ From: Mark Struberg <[email protected]> To: [email protected] Sent: Wed, March 24, 2010 2:01:26 PM Subject: Re: attention - danger zone ;) 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 ___________________________________________________________________ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
