Since I did all my work in git anyway, it's easy for me to merge this later and do some cleanup on the upstream codebase in the meantime.
So feel free to check in again. I think I now also found the root cause of a lot of the bugs I see. They do not happen in the TCK, because there you 'only' play through 1 scenario and cleanup the whole container afterwards. But if you work with the container for a longer period, you will also see what bugs me: We really should get rid of the AbstractContext#creationalContextMap. This damn thing contains 'old' creational contexts. Consider the following scenario: We have a XxxContext which resolves a bean. The bean lies on a movable storage like e.g. the Session or the JSF ViewMap. After switching to another storage, all the stored information of this bean must get switched. But you changed the logic to store the original CreationalContext in the AbstractContext#creationalContextMap (I would have prefered cleaning up the CreationalContext logic itself), and this will only get cleaned up if the Context itself gets terminated. Since there is by design only 1 Context for 1 Scope annotation, this usually only happens at the time the container shuts down. If you still don't believe the fact with the 1:1 from scope to context instance, then please reread the spec on this, 6.2 and especially 11.5.2. AfterBeanDiscovery#addContext(Context). Gavin also clarified this on the list a few months ago. I don't think we need to change this for our internal contexts, but we must assume that in the worst case (all custom contexts) we only have a 1:1! To proof this: there is for example no way we could implement our current n context instances via a portable extension! Any ideas how to solve this are highly welcome. 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 15:27 Uhr > 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! __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
