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 <[email protected]>
> 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 <[email protected]
> >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
