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