could you look at geronimo or openejb codebase or any other projects :))? I think that there is no need that everybody understands every points of codebase
________________________________ From: Mark Struberg <[email protected]> To: [email protected] Sent: Wed, March 24, 2010 4:08:23 PM Subject: Re: attention - danger zone ;) Are there any others beside us two who understand how the current interceptor stuff works? If not, then that's a pretty good sign that it is too complex. 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 14:27 Uhr > >>>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! > > What others think about this? Is it ok to commit something > when owner think that it is OK from his side? My concern is > that if we change something that is under the danger zone, > at least it does followings; > > * Passes all of our internal tests > * Runs against TCKs and it must pass tests that latest > codebase is passed > * And if we have time, tests our examples. Actually we have > a great number of examples for different environments. > > Thanks; > > --Gurkan > > > > > > ________________________________ > From: Gurkan Erdogdu <[email protected]> > To: [email protected] > Sent: Wed, March 24, 2010 2:43:39 PM > Subject: Re: attention - danger zone ;) > > 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! > > > > ___________________________________________________________________ > 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 ___________________________________________________________________ Yahoo! Türkiye açıldı! http://yahoo.com.tr İnternet üzerindeki en iyi içeriği Yahoo! Türkiye sizlere sunuyor!
