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 > >
