[weld-dev] What's the actual meaning of BeanManager.resolveDecorators?

Marius Bogoevici marius.bogoevici at gmail.com
Wed Feb 3 09:58:54 EST 2010


Thanks Gavin. 

On 2010-02-03, at 9:42 AM, Gavin King wrote:

> Definitely (a).
> 
> On Wed, Feb 3, 2010 at 8:28 AM, Marius Bogoevici
> <marius.bogoevici at gmail.com> wrote:
>> Hey,
>> We have an outstanding issue regarding decorators resolution. The problem is
>> caused by the way Weld currently interprets the resolution of decorators.
>> The use can be found in the TCK,
>> inorg.jboss.jsr299.tck.tests.decorators.custom.CustomDecoratorTest.testCustomImplementationOfDecoratorInterface()
>> 
>> 1) We have a Decorator whose decoratedTypes set is {Vehicle} - in this case
>> it is custom, but this is not necessarily a precondition
>> 2) We have a ManagedBean of the type Bus which implements Vehicle
>> 3) BeanManger.resolveDecorators({Bus}) returns nothing
>> 
>> Item #3 causes the test to fail. I read the specification and discussed this
>> with Pete as well, and it's not very clear to both of us what is the intent
>> of the specification in this case. So, here are the relevant parts:
>> 
>> 11.3.11 (Decorator Resolution) states that: "The method
>> BeanManager.resolveDecorators() returns the ordered list of decorators for a
>> set of bean types and a set of qualifiers [...]" and that "The first
>> argument is the set of bean types of the decorated bean.". The method does
>> not seem to have been designed for classes, but for ManagedBeans, whose bean
>> types include the bean class and its supertypes (and in the case of custom
>> beans, they could potentially decide what types they do or don't have).
>> 
>> There are two possible interpretations:
>> 
>> a) the one which is currently applied in Weld: one must specify *all* bean
>> types of a managed bean when invoking resolveDecorators(), otherwise said
>> "VehicleDecorator does not decorate Bus, but it decorates Vehicle"
>> 
>> b) a more relaxed approach, where the supertypes are inferred from the
>> arguments as well, so that resolveDecorators({Bus}) is in all respects
>> equivalent to resolveDecorators({Bus, Vehicle})
>> 
>> It should be noted that this has no practical consequence on the way Weld
>> works internally, as decorator resolution for Weld beans is always performed
>> against the whole set of bean types. However, this will affect the way in
>> which extensions to the framework work.
>> 
>> Common sense would dictate to follow b), since Bus implements Vehicle
>> indeed. However, as I explained before, this does not seem to be what the
>> specification currently says. The only possible reasoning I can see behind
>> that is that a managed bean may not include all its supertypes in
>> getTypes(), therefore it would be wrong to assume that a certain decorator
>> is applicable in its case.
>> 
>> So, what is the actual meaning of BeanManager.resolveDecorators()?
>> Cheers,
>> Marius
> 
> 
> 
> -- 
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org




More information about the weld-dev mailing list