Gavin, Mark and I had a discussion tonight about decorators, trying to clarify some aspects of the specification. It would be great if you could review the statements/comments/use cases described below and indicate what is correct, what isn't, how will the spec address this in the future, etc. It is a long message, but I tried to err by being too verbose rather than risking to leave something out. So, the main themes of the discussion were: a) what are the decorated types of the decorator how do we identify them and what role do they play? b) what are the beans that a decorator can decorate? c) reviewing a few examples that illustrate the various points being made. So, I think that a) could be answered by looking at the preamble of chapter 8, which states that "A decorator implements one or more bean types and intercepts business method invocations of beans which implement those bean types. These bean types are called decorated types" and 8.1 which states that "The set of decorated types of a decorator includes all interfaces implemented directly or indirectly by the bean class, except for java.io.Serializable" The role of decorated types is laid out by 8.1.3 which states "The decorator intercepts every method: • declared by a decorated type of the decorator [...]" b)On the other hand, I read 8.3 as saying that a decorator can decorate only beans which are injectable as delegates ("The bean is eligible for injection to the delegate injection point according to the rules defined in Section 5.3, “Typesafe resolution”.") Overall, it seems like there are two competing restrictions at play: that a decorator can decorate only methods defined on the decorated types (so methods which are not on the decorated types will be ignored) and it can decorate only beans which are injectable as delegates. It should be noted that, according to Mark, quoting Pete (and I can see the same in the code) - Weld does not look at the interfaces implemented by the @Decorator bean in order to retrieve the decorated types, but it infers them from the type of the delegate. (I personally think this violates 8.1, but Pete - in CC - knows better what are the reasons for this). Now, it may happen that a method is defined on the decorator and the target class, but not on any type implemented by the decorator - according to a) and 8.1.3, it won't be used to decorate anything. But in Weld, for example, since the decorated types are inferred from the @Delegate, it will be used for decoration anyway,. The main question raised by Mark during the discussion was what is the use for having the Decorator implement an interface, when for practical purposes, the decorated types are indicated by the delegate type. Furthermore, if a decorator decorates more than one type/interface, what is the type of the injected delegate? The only possible solution now is a type which implements/extends both interfaces, which means that only a bean of that class or a subclass of it (including implementors if we're talking about an interface) can be decorated. Apparently, this is possible because of the gap in the specification that Gavin mentioned yesterday, which allows concrete types to be delegates. If the gap was closed by eliminating concrete classes, then you can't have a decorator that decorates more than one interface. The delegate type restricts the eligible beans anyway (only beans that implement/extend this class are eligible), but why is then necessary to indicate a number of interface types which can be decorated? My take on this is that you may not want to decorate all methods on the delegate, only certain methods and requiring the decorator bean to state the interfaces it wants to decorate can be used for that purpose. But Mark has a point here, that you can achieve the same result by just not implementing those methods, so the requirement for the decorator to implement certain interfaces could be considered superfluous. c) Samples Let's look at an example provided by Mark: class Cat { String getName() {return "";}}; class AngoraCat extends Cat { boolean getHairLength() {return true}} class SiamCat extends Cat { }; @Decorator CatDecorator { @Delegate Cat c; String getName() { log.info("something"); return c.getName(); } } Now, looking at this sample it seems like: (ASSERTION 1) In the sample above there are no decorated types, therefore no actual decoration takes place. Let's add Pet, an interface and have Cat implement it class Pet { String getRegistrationNumber()}; (ASSERTION 2) The set of decorated types consists of the interface Pet. Now let's consider the following two decorators: @Decorator PetDecorator implements Pet {@Delegate Pet p; String getName() { log.info("something"); return c.getName(); }} @Decorator CatDecorator { @Delegate Cat c; String getName() { log.info("something"); return c.getName(); } } (ASSERTION 3) With the modification above, both PetDecorator and CatDecorator apply to all types of cats, but PetDecorator also applies to Pets which are not Cats Now, if we had: interface Cat { String getName();}; class SiamCat implements Cat, Pet { }; class RussianForestCat implements Cat, Pet { }; @Decorator PetCatDecorator implements Cat,Pet {@Delegate SiamCat c; String getName() { log.info("something"); return c.getName(); }} (ASSERTION 4) PetCat will decorate SiamCat but not RussianForestCat (won't even be picked up as a decorator since it does not meet 8.3 wrt RussianForestCat So - Gavin, please also indicate which of these use cases is valid and which assertions hold or not. Mark, I tried to lay out your questions/opinions, as well as mine, as accurate as I could. Feel free to comment/add anything you think is relevant. I think it is important to agree on both the letter as well as the spirit of the specification. Cheers, Marius