Sorry, my sentences were ambiguous, I try to be more specific: > We really should get rid of the > AbstractContext#creationalContextMap
What I mean is that we must not access this from outside the actual context (e.g. in NormalScopedBeanInterceptorHandler), but only handle it as a pure internal data holder of our internal contexts. And we really need to rollback this from CustomContextImpl since we don't have it under control here. LieGrue, strub --- Mark Struberg <[email protected]> schrieb am Mi, 24.3.2010: > Von: Mark Struberg <[email protected]> > Betreff: Re: attention - danger zone ;) > An: [email protected] > Datum: Mittwoch, 24. März, 2010 17:49 Uhr > 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 > __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
