Very good example! Assumed that a,b,c are all @Dependent, the spec defines that all 3 intances MUST be hold in the SAME CreationalContext!
LieGrue, strub --- Gurkan Erdogdu <[email protected]> schrieb am Mi, 24.3.2010: > Von: Gurkan Erdogdu <[email protected]> > Betreff: Re: AW: Rational Behind Current Interceptor/Decorator > Handling/Creational Context > An: [email protected] > Datum: Mittwoch, 24. März, 2010 13:26 Uhr > There is > > a --> b --> c > > a...@inject b} > b...@inject c} > c{ @Inject a} > > c uses b's creational context and b uses a's creational > context for injecting a . > > > Look at BeanManagerImpl# getInjectableReference. > > > > > ________________________________ > From: Mark Struberg <[email protected]> > To: [email protected] > Sent: Wed, March 24, 2010 2:10:30 PM > Subject: Re: AW: Rational Behind Current > Interceptor/Decorator Handling/Creational Context > > Gurkan, the point is that there is no rational behind > having an OwnerCreationalContext! > > So please stay on the topic. > > LieGrue, > strub > > --- Gurkan Erdogdu <[email protected]> > schrieb am Mi, 24.3.2010: > > > Von: Gurkan Erdogdu <[email protected]> > > Betreff: Re: AW: Rational Behind Current > Interceptor/Decorator Handling/Creational Context > > An: [email protected] > > Datum: Mittwoch, 24. März, 2010 12:18 Uhr > > Not everything must be on the > > specification! > > > > 2010/3/24 Mark Struberg <[email protected]> > > > > > Txs Gurkan. > > > > > > Sorry to discuss so long about such small parts, > but > > in my opinion, we > > > should first really get the same understanding, > and > > then the changes will be > > > obvious. > > > > > > On topic: > > > > > > I understand the need to keep track of 'chaining > > dependencies'. > > > > > > But there are no such things like chaining > > dependencies based on _other_ > > > CreationalContexts in the spec! > > > > > > Imo, either a contextual instance is created in > the > > same CreationalContext > > > as another one (a) or it should get it's own > > CreationalContext (b). > > > > > > For (a) the 'chaining dependencies' should get > stored > > in form of a tree. > > > I'm completely d' accord with you in this point, > but I > > think we can > > > completely drop the 'OwnerCreationalContext > thingy'. > > There is no such thing, > > > they all belong to the same CreationalContext. > > > > > > wdyt? > > > > > > LieGrue, > > > strub > > > > > > --- Gurkan Erdogdu <[email protected]> > > schrieb am Mi, 24.3.2010: > > > > > > > Von: Gurkan Erdogdu <[email protected]> > > > > Betreff: Re: AW: Rational Behind Current > > Interceptor/Decorator > > > Handling/Creational Context > > > > An: [email protected] > > > > Datum: Mittwoch, 24. März, 2010 08:03 Uhr > > > > >>>Is this a leftover from > > > > an old period? Or is there some logic > behind > > which is well > > > > hidden from me? > > > > I have explained it lots of time, please > look at > > old emails > > > > about this :) It is used for getting > chaining > > dependencies. > > > > > > > > > > > > --Gurkan > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > From: Mark Struberg <[email protected]> > > > > To: [email protected] > > > > Sent: Tue, March 23, 2010 10:13:32 PM > > > > Subject: AW: Rational Behind Current > > Interceptor/Decorator > > > > Handling/Creational Context > > > > > > > > I understand what the CreationalContext is > for in > > the spec, > > > > but I'm currently hunting for explanations > for > > some helper > > > > constructs like e.g. the > > DependentCreationalContext. > > > > > > > > Either a dependent object is created in the > same > > > > CreationalContext or not, but we currently > are > > forced to > > > > create new 'dummy' CreationalContexts only > to add > > a > > > > dependent contextual instance to the > already > > existing > > > > CreationalContext of the bean it depends on. > That > > looks > > > > weird to me. > > > > > > > > Is this a leftover from an old period? Or > is > > there some > > > > logic behind which is well hidden from me? > > > > > > > > > > > > txs and LieGrue, > > > > strub > > > > > > > > --- Gurkan Erdogdu <[email protected]> > > > > schrieb am Di, 23.3.2010: > > > > > > > > > Von: Gurkan Erdogdu <[email protected]> > > > > > Betreff: Rational Behind Current > > Interceptor/Decorator > > > > Handling/Creational Context > > > > > An: [email protected] > > > > > Datum: Dienstag, 23. März, 2010 20:53 > Uhr > > > > > Hello; > > > > > > > > > > Subject is a little long :) > > > > > > > > > > I would like to explain some of the > design > > rational > > > > of > > > > > current code in regard to using > > CreationalContext and > > > > > handling of Decroators/Interceptors. > > Creational > > > > context is > > > > > implemented by the > CreationalContextImpl and > > is used > > > > for > > > > > saving dependent instances of the > > NormalScoped beans, > > > > i.e > > > > > saving dependent bean instance, > decorstors, > > > > interceptors, > > > > > ejb interceptors etc. > > > > > > > > > > In first creation of the normal scoped > bean > > instance, > > > > it is > > > > > created and saved in the > AbstractContext. > > After that > > > > all of > > > > > its dependents are getting from this > > cretional > > > > context. > > > > > NormalScopedBeansInterceptorHandler > uses > > this semantic > > > > to > > > > > get its creational context and setup > > decorators and > > > > > interceptors. > > > > > > > > > > Moreover, decorators and interceptors > of the > > bean > > > > instance > > > > > is setup only once and saved in > creational > > context > > > > .After > > > > > destroying bean contexts, bean's > cretional > > contexts > > > > are > > > > > destroyed by the container. > > > > > > > > > > Therefore, current code base is hugely > > dependent on > > > > usage > > > > > of CreationalContextImpl class. > > > > > > > > > > Currently, we pass all of the > standalone > > tests(some > > > > issues > > > > > have written to CDI TCK jira) and huge > part > > of the > > > > web > > > > > profile tests. Before changing > critical > > parts of the > > > > > codebase, please run TCK before > committing > > them. > > > > > > > > > > But it always needs another eye to find > out > > more > > > > elegant > > > > > solution. But we have really arrived in > a > > good point > > > > and > > > > > care must be taken to not broke the > running > > code :) > > > > > > > > > > Thanks; > > > > > > > > > > --Gurkan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___________________________________________________________________ > > > > > 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 > > > > > > > > > > > -- > > 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! __________________________________________________ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
