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
