You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by David Blevins <da...@visi.com> on 2009/10/16 00:06:10 UTC
Decorators and @Decorates injection
We don't currently support this and implementing it correctly will
actually be tricky. I recommend we ignore everything I'm about to say
and just implement it naively for the sake of simplicity and come back
and make this change later.
The trick: you can't inject the delegate while creating the chain on
the fly during a pending invoke.
The reason being is a single Decorator instance can apply to several
beans and therefore could be executed concurrently. All invocations
to those beans will funnel through the same Decorator instance. With
Interceptors this is not an issue as the delegate is essentially
passed into the around invoke method. With Decorators, it's a field,
and overwriting it while it's being accessed by other threads is the
definition of not thread-safe.
We're essentially going to need to inject a proxy-like object as the
delegate and do that once when the Decorator is created. That
delegate will have to look in a thread local in some way for the next
guy down the chain and send calls to it.
That will actually be somewhat of an effort as this is all strongly
typed -- we actually need to implement the interface which means well
be making one of these for each interface type that can be decorated.
This is old-hat in app server land, but will be a bit of an
undertaking. Fortunately, one that can be done as an isolated change
unrelated to the basic concept of having a stack.
We can just do this ignoring thread saftey at first and then get that
in there once things look good generally. That's my recommendation
anyways. Getting small changes in frequently is usually better than
saying "no one touch this code I'm working on it" and have that go on
for more than a few days, which is an easy pit to fall into when
simple problems continue to get more complicated. Figured I'd mention
it up front as the above problem is an easy pit to fall into.
-David
Re: Decorators and @Decorates injection
Posted by David Blevins <da...@visi.com>.
If that's the case then, great, we can just build the stack when the
bean is created and leave it fixed.
-David
On Oct 16, 2009, at 2:34 AM, Gurkan Erdogdu wrote:
> Hi David;
>
> I thought that if decorator beans are defined with scope @Dependent
> it seems that no problem occurs regarding thread safety. Because,
> every time container gets its instance, there will be a new
> decorator instance.
>
>
> But at the overall, those concerns are all fine.
>
> Thanks;
>
> --Gurkan
>
>
>
>
> ________________________________
> From: David Blevins <da...@visi.com>
> To: openwebbeans-dev@incubator.apache.org
> Sent: Fri, October 16, 2009 1:06:10 AM
> Subject: Decorators and @Decorates injection
>
> We don't currently support this and implementing it correctly will
> actually be tricky. I recommend we ignore everything I'm about to
> say and just implement it naively for the sake of simplicity and
> come back and make this change later.
>
>
> The trick: you can't inject the delegate while creating the chain on
> the fly during a pending invoke.
>
> The reason being is a single Decorator instance can apply to several
> beans and therefore could be executed concurrently. All invocations
> to those beans will funnel through the same Decorator instance.
> With Interceptors this is not an issue as the delegate is
> essentially passed into the around invoke method. With Decorators,
> it's a field, and overwriting it while it's being accessed by other
> threads is the definition of not thread-safe.
>
> We're essentially going to need to inject a proxy-like object as the
> delegate and do that once when the Decorator is created. That
> delegate will have to look in a thread local in some way for the
> next guy down the chain and send calls to it.
>
> That will actually be somewhat of an effort as this is all strongly
> typed -- we actually need to implement the interface which means
> well be making one of these for each interface type that can be
> decorated. This is old-hat in app server land, but will be a bit of
> an undertaking. Fortunately, one that can be done as an isolated
> change unrelated to the basic concept of having a stack.
>
> We can just do this ignoring thread saftey at first and then get
> that in there once things look good generally. That's my
> recommendation anyways. Getting small changes in frequently is
> usually better than saying "no one touch this code I'm working on
> it" and have that go on for more than a few days, which is an easy
> pit to fall into when simple problems continue to get more
> complicated. Figured I'd mention it up front as the above problem
> is an easy pit to fall into.
>
>
> -David
>
>
Re: Decorators and @Decorates injection
Posted by Gurkan Erdogdu <gu...@yahoo.com>.
Hi David;
I thought that if decorator beans are defined with scope @Dependent it seems that no problem occurs regarding thread safety. Because, every time container gets its instance, there will be a new decorator instance.
But at the overall, those concerns are all fine.
Thanks;
--Gurkan
________________________________
From: David Blevins <da...@visi.com>
To: openwebbeans-dev@incubator.apache.org
Sent: Fri, October 16, 2009 1:06:10 AM
Subject: Decorators and @Decorates injection
We don't currently support this and implementing it correctly will actually be tricky. I recommend we ignore everything I'm about to say and just implement it naively for the sake of simplicity and come back and make this change later.
The trick: you can't inject the delegate while creating the chain on the fly during a pending invoke.
The reason being is a single Decorator instance can apply to several beans and therefore could be executed concurrently. All invocations to those beans will funnel through the same Decorator instance. With Interceptors this is not an issue as the delegate is essentially passed into the around invoke method. With Decorators, it's a field, and overwriting it while it's being accessed by other threads is the definition of not thread-safe.
We're essentially going to need to inject a proxy-like object as the delegate and do that once when the Decorator is created. That delegate will have to look in a thread local in some way for the next guy down the chain and send calls to it.
That will actually be somewhat of an effort as this is all strongly typed -- we actually need to implement the interface which means well be making one of these for each interface type that can be decorated. This is old-hat in app server land, but will be a bit of an undertaking. Fortunately, one that can be done as an isolated change unrelated to the basic concept of having a stack.
We can just do this ignoring thread saftey at first and then get that in there once things look good generally. That's my recommendation anyways. Getting small changes in frequently is usually better than saying "no one touch this code I'm working on it" and have that go on for more than a few days, which is an easy pit to fall into when simple problems continue to get more complicated. Figured I'd mention it up front as the above problem is an easy pit to fall into.
-David
Re: Decorators and @Decorates injection
Posted by Gurkan Erdogdu <cg...@gmail.com>.
In the mean time it seems that we do not check "generic type" in the method
"isDecoratorMatch". We can also check type compatibility for parameterized
types.
--Gurkan
2009/10/16 Gurkan Erdogdu <cg...@gmail.com>
> Hi Joe;
>
> Right now it appears openwebbeans attempts to match all of the bean
>> qualifiers to the delegate qualifiers to determine if the decorator is a
>> @Decorates @Default @Named @All InterfaceA a;
>>
>
> If current implementation works like this, this is a certainly a bug.
>
> The example in the spec also only uses @All, perhaps because @Default is
>> assumed in cases where no other qualifiers exist and technicall @Named is
>> qualifier.
>>
>> @Decorates @Any Logger logger;
>>
>
> This example tries to explain that if a decorator is applicable for a
> bean, its delegate injection point can be resolved to this bean. In the
> example, any bean has a type {Logger} and has a qualifier {@Any} will get
> this decorator into its decorator stack. Similarly, spec. explains this via
> directing the reader to section 5.3.
>
> This actually means that if I call
>
> BeanManager#getBeans({Looger}, {@Any}) returns --> Set<Beans> --> contains
> --> Owner Beans of this decorator. So this is not really necessary to
> compare all qualifiers of bean with delegate injection point qualifier.
>
>
> If that is the case, this seems like it would be a pretty simple change to
>> isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I
>> am
>> interpreting it correctly.
>>
>
> Actually, we can change the isDecoratorMatch method implementation to
> satisfy spec. requirement.
>
> --Gurkan
>
> 2009/10/16 Joseph Bergmark <be...@gmail.com>
>
> While not directly related, one thing I've been struggling with a bit are
>> the delegate qualifiers. The spec introduces the term, but doesn't get
>> into
>> much detail regarding how they are used when matching the decorator to the
>> decorated bean.
>>
>> Right now it appears openwebbeans attempts to match all of the bean
>> qualifiers to the delegate qualifiers to determine if the decorator is a
>> match. For example, if I had a bean that was @Named and @RequestScoped
>> and
>> implements InterfaceA, I would need the delegate injection point to be
>> annotated as follows:
>>
>> @Decorates @Default @Named @All InterfaceA a;
>>
>> This seems odd for a couple reasons. 1) The spec discourages using @Named
>> in injection points except when interacting with legacy code in 3.11. 2)
>> It
>> feels like we shouldn't have to list @Default here as normally that is
>> kind
>> of a freebie when the bean doesn't have any qualifier other than @Named.
>>
>> The example in the spec also only uses @All, perhaps because @Default is
>> assumed in cases where no other qualifiers exist and technicall @Named is
>> qualifier.
>>
>> @Decorates @Any Logger logger;
>>
>> However the Decorators section does say that beans are eligible for
>> injection into delegate injection points based on the rules in 5.3. It
>> isn't clear to me that 5.3 isn't saying that all of the specified
>> qualifiers
>> on the injection points need to be present in the bean and not vice versa.
>>
>> If that is the case, this seems like it would be a pretty simple change to
>> isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I
>> am
>> interpreting it correctly.
>>
>> Sincerely,
>>
>> Joe
>>
>> On Thu, Oct 15, 2009 at 6:06 PM, David Blevins <david.blevins@visi.com
>> >wrote:
>>
>> > We don't currently support this and implementing it correctly will
>> actually
>> > be tricky. I recommend we ignore everything I'm about to say and just
>> > implement it naively for the sake of simplicity and come back and make
>> this
>> > change later.
>> >
>> >
>> > The trick: you can't inject the delegate while creating the chain on the
>> > fly during a pending invoke.
>> >
>> > The reason being is a single Decorator instance can apply to several
>> beans
>> > and therefore could be executed concurrently. All invocations to those
>> > beans will funnel through the same Decorator instance. With
>> Interceptors
>> > this is not an issue as the delegate is essentially passed into the
>> around
>> > invoke method. With Decorators, it's a field, and overwriting it while
>> it's
>> > being accessed by other threads is the definition of not thread-safe.
>> >
>> > We're essentially going to need to inject a proxy-like object as the
>> > delegate and do that once when the Decorator is created. That delegate
>> will
>> > have to look in a thread local in some way for the next guy down the
>> chain
>> > and send calls to it.
>> >
>> > That will actually be somewhat of an effort as this is all strongly
>> typed
>> > -- we actually need to implement the interface which means well be
>> making
>> > one of these for each interface type that can be decorated. This is
>> old-hat
>> > in app server land, but will be a bit of an undertaking. Fortunately,
>> one
>> > that can be done as an isolated change unrelated to the basic concept of
>> > having a stack.
>> >
>> > We can just do this ignoring thread saftey at first and then get that in
>> > there once things look good generally. That's my recommendation
>> anyways.
>> > Getting small changes in frequently is usually better than saying "no
>> one
>> > touch this code I'm working on it" and have that go on for more than a
>> few
>> > days, which is an easy pit to fall into when simple problems continue to
>> get
>> > more complicated. Figured I'd mention it up front as the above problem
>> is
>> > an easy pit to fall into.
>> >
>> >
>> > -David
>> >
>> >
>>
>
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Decorators and @Decorates injection
Posted by Joseph Bergmark <be...@gmail.com>.
I will go ahead and open a JIRA ticket for this. I believe the change to
isDecoratorMatch should be pretty straight foward so I'll attach a patch as
well. Thanks for the clarification!
Sincerely,
Joe Bergmark
On Fri, Oct 16, 2009 at 8:56 AM, Gurkan Erdogdu <cg...@gmail.com>wrote:
> Hi Joe;
>
> Right now it appears openwebbeans attempts to match all of the bean
> > qualifiers to the delegate qualifiers to determine if the decorator is a
> > @Decorates @Default @Named @All InterfaceA a;
> >
>
> If current implementation works like this, this is a certainly a bug.
>
> The example in the spec also only uses @All, perhaps because @Default is
> > assumed in cases where no other qualifiers exist and technicall @Named is
> > qualifier.
> >
> > @Decorates @Any Logger logger;
> >
>
> This example tries to explain that if a decorator is applicable for a
> bean, its delegate injection point can be resolved to this bean. In the
> example, any bean has a type {Logger} and has a qualifier {@Any} will get
> this decorator into its decorator stack. Similarly, spec. explains this via
> directing the reader to section 5.3.
>
> This actually means that if I call
>
> BeanManager#getBeans({Looger}, {@Any}) returns --> Set<Beans> --> contains
> --> Owner Beans of this decorator. So this is not really necessary to
> compare all qualifiers of bean with delegate injection point qualifier.
>
>
> If that is the case, this seems like it would be a pretty simple change to
> > isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I
> > am
> > interpreting it correctly.
> >
>
> Actually, we can change the isDecoratorMatch method implementation to
> satisfy spec. requirement.
>
> --Gurkan
>
> 2009/10/16 Joseph Bergmark <be...@gmail.com>
>
> > While not directly related, one thing I've been struggling with a bit are
> > the delegate qualifiers. The spec introduces the term, but doesn't get
> > into
> > much detail regarding how they are used when matching the decorator to
> the
> > decorated bean.
> >
> > Right now it appears openwebbeans attempts to match all of the bean
> > qualifiers to the delegate qualifiers to determine if the decorator is a
> > match. For example, if I had a bean that was @Named and @RequestScoped
> and
> > implements InterfaceA, I would need the delegate injection point to be
> > annotated as follows:
> >
> > @Decorates @Default @Named @All InterfaceA a;
> >
> > This seems odd for a couple reasons. 1) The spec discourages using
> @Named
> > in injection points except when interacting with legacy code in 3.11. 2)
> > It
> > feels like we shouldn't have to list @Default here as normally that is
> kind
> > of a freebie when the bean doesn't have any qualifier other than @Named.
> >
> > The example in the spec also only uses @All, perhaps because @Default is
> > assumed in cases where no other qualifiers exist and technicall @Named is
> > qualifier.
> >
> > @Decorates @Any Logger logger;
> >
> > However the Decorators section does say that beans are eligible for
> > injection into delegate injection points based on the rules in 5.3. It
> > isn't clear to me that 5.3 isn't saying that all of the specified
> > qualifiers
> > on the injection points need to be present in the bean and not vice
> versa.
> >
> > If that is the case, this seems like it would be a pretty simple change
> to
> > isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I
> > am
> > interpreting it correctly.
> >
> > Sincerely,
> >
> > Joe
> >
> > On Thu, Oct 15, 2009 at 6:06 PM, David Blevins <david.blevins@visi.com
> > >wrote:
> >
> > > We don't currently support this and implementing it correctly will
> > actually
> > > be tricky. I recommend we ignore everything I'm about to say and just
> > > implement it naively for the sake of simplicity and come back and make
> > this
> > > change later.
> > >
> > >
> > > The trick: you can't inject the delegate while creating the chain on
> the
> > > fly during a pending invoke.
> > >
> > > The reason being is a single Decorator instance can apply to several
> > beans
> > > and therefore could be executed concurrently. All invocations to those
> > > beans will funnel through the same Decorator instance. With
> Interceptors
> > > this is not an issue as the delegate is essentially passed into the
> > around
> > > invoke method. With Decorators, it's a field, and overwriting it while
> > it's
> > > being accessed by other threads is the definition of not thread-safe.
> > >
> > > We're essentially going to need to inject a proxy-like object as the
> > > delegate and do that once when the Decorator is created. That delegate
> > will
> > > have to look in a thread local in some way for the next guy down the
> > chain
> > > and send calls to it.
> > >
> > > That will actually be somewhat of an effort as this is all strongly
> typed
> > > -- we actually need to implement the interface which means well be
> making
> > > one of these for each interface type that can be decorated. This is
> > old-hat
> > > in app server land, but will be a bit of an undertaking. Fortunately,
> > one
> > > that can be done as an isolated change unrelated to the basic concept
> of
> > > having a stack.
> > >
> > > We can just do this ignoring thread saftey at first and then get that
> in
> > > there once things look good generally. That's my recommendation
> anyways.
> > > Getting small changes in frequently is usually better than saying "no
> > one
> > > touch this code I'm working on it" and have that go on for more than a
> > few
> > > days, which is an easy pit to fall into when simple problems continue
> to
> > get
> > > more complicated. Figured I'd mention it up front as the above problem
> > is
> > > an easy pit to fall into.
> > >
> > >
> > > -David
> > >
> > >
> >
>
>
>
> --
> Gurkan Erdogdu
> http://gurkanerdogdu.blogspot.com
>
Re: Decorators and @Decorates injection
Posted by Gurkan Erdogdu <cg...@gmail.com>.
Hi Joe;
Right now it appears openwebbeans attempts to match all of the bean
> qualifiers to the delegate qualifiers to determine if the decorator is a
> @Decorates @Default @Named @All InterfaceA a;
>
If current implementation works like this, this is a certainly a bug.
The example in the spec also only uses @All, perhaps because @Default is
> assumed in cases where no other qualifiers exist and technicall @Named is
> qualifier.
>
> @Decorates @Any Logger logger;
>
This example tries to explain that if a decorator is applicable for a
bean, its delegate injection point can be resolved to this bean. In the
example, any bean has a type {Logger} and has a qualifier {@Any} will get
this decorator into its decorator stack. Similarly, spec. explains this via
directing the reader to section 5.3.
This actually means that if I call
BeanManager#getBeans({Looger}, {@Any}) returns --> Set<Beans> --> contains
--> Owner Beans of this decorator. So this is not really necessary to
compare all qualifiers of bean with delegate injection point qualifier.
If that is the case, this seems like it would be a pretty simple change to
> isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I
> am
> interpreting it correctly.
>
Actually, we can change the isDecoratorMatch method implementation to
satisfy spec. requirement.
--Gurkan
2009/10/16 Joseph Bergmark <be...@gmail.com>
> While not directly related, one thing I've been struggling with a bit are
> the delegate qualifiers. The spec introduces the term, but doesn't get
> into
> much detail regarding how they are used when matching the decorator to the
> decorated bean.
>
> Right now it appears openwebbeans attempts to match all of the bean
> qualifiers to the delegate qualifiers to determine if the decorator is a
> match. For example, if I had a bean that was @Named and @RequestScoped and
> implements InterfaceA, I would need the delegate injection point to be
> annotated as follows:
>
> @Decorates @Default @Named @All InterfaceA a;
>
> This seems odd for a couple reasons. 1) The spec discourages using @Named
> in injection points except when interacting with legacy code in 3.11. 2)
> It
> feels like we shouldn't have to list @Default here as normally that is kind
> of a freebie when the bean doesn't have any qualifier other than @Named.
>
> The example in the spec also only uses @All, perhaps because @Default is
> assumed in cases where no other qualifiers exist and technicall @Named is
> qualifier.
>
> @Decorates @Any Logger logger;
>
> However the Decorators section does say that beans are eligible for
> injection into delegate injection points based on the rules in 5.3. It
> isn't clear to me that 5.3 isn't saying that all of the specified
> qualifiers
> on the injection points need to be present in the bean and not vice versa.
>
> If that is the case, this seems like it would be a pretty simple change to
> isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I
> am
> interpreting it correctly.
>
> Sincerely,
>
> Joe
>
> On Thu, Oct 15, 2009 at 6:06 PM, David Blevins <david.blevins@visi.com
> >wrote:
>
> > We don't currently support this and implementing it correctly will
> actually
> > be tricky. I recommend we ignore everything I'm about to say and just
> > implement it naively for the sake of simplicity and come back and make
> this
> > change later.
> >
> >
> > The trick: you can't inject the delegate while creating the chain on the
> > fly during a pending invoke.
> >
> > The reason being is a single Decorator instance can apply to several
> beans
> > and therefore could be executed concurrently. All invocations to those
> > beans will funnel through the same Decorator instance. With Interceptors
> > this is not an issue as the delegate is essentially passed into the
> around
> > invoke method. With Decorators, it's a field, and overwriting it while
> it's
> > being accessed by other threads is the definition of not thread-safe.
> >
> > We're essentially going to need to inject a proxy-like object as the
> > delegate and do that once when the Decorator is created. That delegate
> will
> > have to look in a thread local in some way for the next guy down the
> chain
> > and send calls to it.
> >
> > That will actually be somewhat of an effort as this is all strongly typed
> > -- we actually need to implement the interface which means well be making
> > one of these for each interface type that can be decorated. This is
> old-hat
> > in app server land, but will be a bit of an undertaking. Fortunately,
> one
> > that can be done as an isolated change unrelated to the basic concept of
> > having a stack.
> >
> > We can just do this ignoring thread saftey at first and then get that in
> > there once things look good generally. That's my recommendation anyways.
> > Getting small changes in frequently is usually better than saying "no
> one
> > touch this code I'm working on it" and have that go on for more than a
> few
> > days, which is an easy pit to fall into when simple problems continue to
> get
> > more complicated. Figured I'd mention it up front as the above problem
> is
> > an easy pit to fall into.
> >
> >
> > -David
> >
> >
>
--
Gurkan Erdogdu
http://gurkanerdogdu.blogspot.com
Re: Decorators and @Decorates injection
Posted by Joseph Bergmark <be...@gmail.com>.
While not directly related, one thing I've been struggling with a bit are
the delegate qualifiers. The spec introduces the term, but doesn't get into
much detail regarding how they are used when matching the decorator to the
decorated bean.
Right now it appears openwebbeans attempts to match all of the bean
qualifiers to the delegate qualifiers to determine if the decorator is a
match. For example, if I had a bean that was @Named and @RequestScoped and
implements InterfaceA, I would need the delegate injection point to be
annotated as follows:
@Decorates @Default @Named @All InterfaceA a;
This seems odd for a couple reasons. 1) The spec discourages using @Named
in injection points except when interacting with legacy code in 3.11. 2) It
feels like we shouldn't have to list @Default here as normally that is kind
of a freebie when the bean doesn't have any qualifier other than @Named.
The example in the spec also only uses @All, perhaps because @Default is
assumed in cases where no other qualifiers exist and technicall @Named is
qualifier.
@Decorates @Any Logger logger;
However the Decorators section does say that beans are eligible for
injection into delegate injection points based on the rules in 5.3. It
isn't clear to me that 5.3 isn't saying that all of the specified qualifiers
on the injection points need to be present in the bean and not vice versa.
If that is the case, this seems like it would be a pretty simple change to
isDecoratorMatch in WebBeansDecorator<T>. I'm just not completely sure I am
interpreting it correctly.
Sincerely,
Joe
On Thu, Oct 15, 2009 at 6:06 PM, David Blevins <da...@visi.com>wrote:
> We don't currently support this and implementing it correctly will actually
> be tricky. I recommend we ignore everything I'm about to say and just
> implement it naively for the sake of simplicity and come back and make this
> change later.
>
>
> The trick: you can't inject the delegate while creating the chain on the
> fly during a pending invoke.
>
> The reason being is a single Decorator instance can apply to several beans
> and therefore could be executed concurrently. All invocations to those
> beans will funnel through the same Decorator instance. With Interceptors
> this is not an issue as the delegate is essentially passed into the around
> invoke method. With Decorators, it's a field, and overwriting it while it's
> being accessed by other threads is the definition of not thread-safe.
>
> We're essentially going to need to inject a proxy-like object as the
> delegate and do that once when the Decorator is created. That delegate will
> have to look in a thread local in some way for the next guy down the chain
> and send calls to it.
>
> That will actually be somewhat of an effort as this is all strongly typed
> -- we actually need to implement the interface which means well be making
> one of these for each interface type that can be decorated. This is old-hat
> in app server land, but will be a bit of an undertaking. Fortunately, one
> that can be done as an isolated change unrelated to the basic concept of
> having a stack.
>
> We can just do this ignoring thread saftey at first and then get that in
> there once things look good generally. That's my recommendation anyways.
> Getting small changes in frequently is usually better than saying "no one
> touch this code I'm working on it" and have that go on for more than a few
> days, which is an easy pit to fall into when simple problems continue to get
> more complicated. Figured I'd mention it up front as the above problem is
> an easy pit to fall into.
>
>
> -David
>
>