There is no need to create those dependent CreationalContexts. This only introduces a lot complexity without providing additional functionality imo.
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:47 Uhr > We put all normal bean dependent > instances into its creational context. Just we create extra > creational context for dependent beans. look at my later > email. > > > > ________________________________ > From: Mark Struberg <[email protected]> > To: [email protected] > Sent: Wed, March 24, 2010 2:34:00 PM > Subject: Re: AW: Rational Behind Current > Interceptor/Decorator Handling/Creational Context > > 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 > > > > > ___________________________________________________________________ > 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
