Definitely (a). On Wed, Feb 3, 2010 at 8:28 AM, Marius Bogoevici <marius.bogoevici(a)gmail.com&gt; 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(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org