You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by Gurkan Erdogdu <gu...@yahoo.com> on 2010/03/23 20:53:20 UTC
Rational Behind Current Interceptor/Decorator Handling/Creational Context
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!
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Mark Struberg <st...@yahoo.de>.
There is no need to create those dependent CreationalContexts. This only introduces a lot complexity without providing additional functionality imo.
LieGrue,
strub
--- Gurkan Erdogdu <gu...@yahoo.com> schrieb am Mi, 24.3.2010:
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> Betreff: Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> 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 <st...@yahoo.de>
> To: dev@openwebbeans.apache.org
> 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 <gu...@yahoo.com>
> schrieb am Mi, 24.3.2010:
>
> > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > Betreff: Re: AW: Rational Behind Current
> Interceptor/Decorator Handling/Creational Context
> > An: dev@openwebbeans.apache.org
> > 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 <st...@yahoo.de>
> > To: dev@openwebbeans.apache.org
> > 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 <cg...@gmail.com>
> > schrieb am Mi, 24.3.2010:
> >
> > > Von: Gurkan Erdogdu <cg...@gmail.com>
> > > Betreff: Re: AW: Rational Behind Current
> > Interceptor/Decorator Handling/Creational
> Context
> > > An: dev@openwebbeans.apache.org
> > > Datum: Mittwoch, 24. März, 2010 12:18 Uhr
> > > Not everything must be on the
> > > specification!
> > >
> > > 2010/3/24 Mark Struberg <st...@yahoo.de>
> > >
> > > > 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 <gu...@yahoo.com>
> > > schrieb am Mi, 24.3.2010:
> > > >
> > > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > > Betreff: Re: AW: Rational Behind
> Current
> > > Interceptor/Decorator
> > > > Handling/Creational Context
> > > > > An: dev@openwebbeans.apache.org
> > > > > 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 <st...@yahoo.de>
> > > > > To: dev@openwebbeans.apache.org
> > > > > 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 <gu...@yahoo.com>
> > > > > schrieb am Di, 23.3.2010:
> > > > >
> > > > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > > > Betreff: Rational Behind Current
> > > Interceptor/Decorator
> > > > > Handling/Creational Context
> > > > > > An: dev@openwebbeans.apache.org
> > > > > > 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
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
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 <st...@yahoo.de>
To: dev@openwebbeans.apache.org
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 <gu...@yahoo.com> schrieb am Mi, 24.3.2010:
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> Betreff: Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> 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 <st...@yahoo.de>
> To: dev@openwebbeans.apache.org
> 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 <cg...@gmail.com>
> schrieb am Mi, 24.3.2010:
>
> > Von: Gurkan Erdogdu <cg...@gmail.com>
> > Betreff: Re: AW: Rational Behind Current
> Interceptor/Decorator Handling/Creational Context
> > An: dev@openwebbeans.apache.org
> > Datum: Mittwoch, 24. März, 2010 12:18 Uhr
> > Not everything must be on the
> > specification!
> >
> > 2010/3/24 Mark Struberg <st...@yahoo.de>
> >
> > > 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 <gu...@yahoo.com>
> > schrieb am Mi, 24.3.2010:
> > >
> > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > Betreff: Re: AW: Rational Behind Current
> > Interceptor/Decorator
> > > Handling/Creational Context
> > > > An: dev@openwebbeans.apache.org
> > > > 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 <st...@yahoo.de>
> > > > To: dev@openwebbeans.apache.org
> > > > 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 <gu...@yahoo.com>
> > > > schrieb am Di, 23.3.2010:
> > > >
> > > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > > Betreff: Rational Behind Current
> > Interceptor/Decorator
> > > > Handling/Creational Context
> > > > > An: dev@openwebbeans.apache.org
> > > > > 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!
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Mark Struberg <st...@yahoo.de>.
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 <gu...@yahoo.com> schrieb am Mi, 24.3.2010:
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> Betreff: Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> 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 <st...@yahoo.de>
> To: dev@openwebbeans.apache.org
> 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 <cg...@gmail.com>
> schrieb am Mi, 24.3.2010:
>
> > Von: Gurkan Erdogdu <cg...@gmail.com>
> > Betreff: Re: AW: Rational Behind Current
> Interceptor/Decorator Handling/Creational Context
> > An: dev@openwebbeans.apache.org
> > Datum: Mittwoch, 24. März, 2010 12:18 Uhr
> > Not everything must be on the
> > specification!
> >
> > 2010/3/24 Mark Struberg <st...@yahoo.de>
> >
> > > 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 <gu...@yahoo.com>
> > schrieb am Mi, 24.3.2010:
> > >
> > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > Betreff: Re: AW: Rational Behind Current
> > Interceptor/Decorator
> > > Handling/Creational Context
> > > > An: dev@openwebbeans.apache.org
> > > > 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 <st...@yahoo.de>
> > > > To: dev@openwebbeans.apache.org
> > > > 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 <gu...@yahoo.com>
> > > > schrieb am Di, 23.3.2010:
> > > >
> > > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > > Betreff: Rational Behind Current
> > Interceptor/Decorator
> > > > Handling/Creational Context
> > > > > An: dev@openwebbeans.apache.org
> > > > > 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
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
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 <st...@yahoo.de>
To: dev@openwebbeans.apache.org
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 <cg...@gmail.com> schrieb am Mi, 24.3.2010:
> Von: Gurkan Erdogdu <cg...@gmail.com>
> Betreff: Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> Datum: Mittwoch, 24. März, 2010 12:18 Uhr
> Not everything must be on the
> specification!
>
> 2010/3/24 Mark Struberg <st...@yahoo.de>
>
> > 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 <gu...@yahoo.com>
> schrieb am Mi, 24.3.2010:
> >
> > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > Betreff: Re: AW: Rational Behind Current
> Interceptor/Decorator
> > Handling/Creational Context
> > > An: dev@openwebbeans.apache.org
> > > 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 <st...@yahoo.de>
> > > To: dev@openwebbeans.apache.org
> > > 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 <gu...@yahoo.com>
> > > schrieb am Di, 23.3.2010:
> > >
> > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > Betreff: Rational Behind Current
> Interceptor/Decorator
> > > Handling/Creational Context
> > > > An: dev@openwebbeans.apache.org
> > > > 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!
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Mark Struberg <st...@yahoo.de>.
Gurkan, the point is that there is no rational behind having an OwnerCreationalContext!
So please stay on the topic.
LieGrue,
strub
--- Gurkan Erdogdu <cg...@gmail.com> schrieb am Mi, 24.3.2010:
> Von: Gurkan Erdogdu <cg...@gmail.com>
> Betreff: Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> Datum: Mittwoch, 24. März, 2010 12:18 Uhr
> Not everything must be on the
> specification!
>
> 2010/3/24 Mark Struberg <st...@yahoo.de>
>
> > 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 <gu...@yahoo.com>
> schrieb am Mi, 24.3.2010:
> >
> > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > Betreff: Re: AW: Rational Behind Current
> Interceptor/Decorator
> > Handling/Creational Context
> > > An: dev@openwebbeans.apache.org
> > > 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 <st...@yahoo.de>
> > > To: dev@openwebbeans.apache.org
> > > 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 <gu...@yahoo.com>
> > > schrieb am Di, 23.3.2010:
> > >
> > > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > > Betreff: Rational Behind Current
> Interceptor/Decorator
> > > Handling/Creational Context
> > > > An: dev@openwebbeans.apache.org
> > > > 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
Re: AW: Rational Behind Current Interceptor/Decorator
Handling/Creational Context
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Not everything must be on the specification!
2010/3/24 Mark Struberg <st...@yahoo.de>
> 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 <gu...@yahoo.com> schrieb am Mi, 24.3.2010:
>
> > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > Betreff: Re: AW: Rational Behind Current Interceptor/Decorator
> Handling/Creational Context
> > An: dev@openwebbeans.apache.org
> > 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 <st...@yahoo.de>
> > To: dev@openwebbeans.apache.org
> > 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 <gu...@yahoo.com>
> > schrieb am Di, 23.3.2010:
> >
> > > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > > Betreff: Rational Behind Current Interceptor/Decorator
> > Handling/Creational Context
> > > An: dev@openwebbeans.apache.org
> > > 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
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Mark Struberg <st...@yahoo.de>.
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 <gu...@yahoo.com> schrieb am Mi, 24.3.2010:
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> Betreff: Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> 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 <st...@yahoo.de>
> To: dev@openwebbeans.apache.org
> 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 <gu...@yahoo.com>
> schrieb am Di, 23.3.2010:
>
> > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > Betreff: Rational Behind Current Interceptor/Decorator
> Handling/Creational Context
> > An: dev@openwebbeans.apache.org
> > 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
Re: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
>>>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 <st...@yahoo.de>
To: dev@openwebbeans.apache.org
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 <gu...@yahoo.com> schrieb am Di, 23.3.2010:
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> Betreff: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> 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!
AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Mark Struberg <st...@yahoo.de>.
The CreationalContextFactory also looks suspect to me.
LieGrue,
strub
--- Mark Struberg <st...@yahoo.de> schrieb am Di, 23.3.2010:
> Von: Mark Struberg <st...@yahoo.de>
> Betreff: AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> Datum: Dienstag, 23. März, 2010 21:13 Uhr
> 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 <gu...@yahoo.com>
> schrieb am Di, 23.3.2010:
>
> > Von: Gurkan Erdogdu <gu...@yahoo.com>
> > Betreff: Rational Behind Current Interceptor/Decorator
> Handling/Creational Context
> > An: dev@openwebbeans.apache.org
> > 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
>
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
AW: Rational Behind Current Interceptor/Decorator Handling/Creational Context
Posted by Mark Struberg <st...@yahoo.de>.
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 <gu...@yahoo.com> schrieb am Di, 23.3.2010:
> Von: Gurkan Erdogdu <gu...@yahoo.com>
> Betreff: Rational Behind Current Interceptor/Decorator Handling/Creational Context
> An: dev@openwebbeans.apache.org
> 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