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