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 <[email protected]> > 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 > -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
