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

Gavin King gavin.king at gmail.com
Wed Feb 3 09:42:40 EST 2010


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