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