I would maybe call the third case a 'subBean".   I have also run into a problem regarding decorators of 'subBeans'. The problem is that is I create a decorator of a subBean then I currently have no way of calling methods in the 'superBean'.   I imagine that the spec may have to be extended with a DI annotation like @SuperBean (@SuperBean like the @Decorates annotation only it is set to a reference that delegates calls to the superBean instead of the the next method in the current stack of interceptors for the subBean). @SuperBean would be used somelike this this...   public interface BaseType {     public String getDescription(); } public class SubType extends BaseType { } @Decorator public BaseTypeImpl implements BaseType {   }     --- On Thu, 11/27/08, Gavin King <gavin(a)hibernate.org&gt; wrote: From: Gavin King <gavin(a)hibernate.org&gt; Subject: [webbeans-dev] Patterns of reuse To: "Java Community Process JSR #299 Expert List" <JSR-299-EG(a)jcp.org&gt;, "Matt Drees" <matt.drees(a)gmail.com&gt;, "Scott Ferguson" <ferg(a)caucho.com&gt;, &quot;webbeans-dev(a)lists.jboss.org&quot; <webbeans-dev(a)lists.jboss.org&gt; Date: Thursday, November 27, 2008, 4:09 PM OK, so I think I've just had a major breakthrough in my thinking about a number of related problems. Today, the spec defines the following: * when you extend a web bean in Java, none of the web bean metadata is inherited from the superclass * when you declare a web bean in XML, some, but not all of the web bean metadata is inherited from the implementation class * you can customize this behavior somewhat via use of @Specializes or <Specializes/> for the special case where you are trying to "override" a web bean in a particular deployment Furthermore, we've been talking about a new feature to customize the behavior for the special case where you are reusing a generic web bean (from a third-party library, for example). What we're missing here is the big picture. We need to model a set of canonical cases of web bean "subtyping". We have two mechanisms for creating subtypes: * extension of the implementation class * declaration via XML The two mechanisms each have advantages and disadvantages, but they both allow the same set of customizations of the web beans metadata. Therefore, I think they should behave identically with respect to "inheritance" of metadata from the supertype to the subtype. This principle will make web beans easier to learn and understand. However, it has become clear that there is no one-size-fits all ruleset for metadata inheritance. So, instead, we've identified the following three patterns of reuse: 1. Pure implementation inheritance: we're only interested in inheriting the Java code. The web beans metadata declared by the supertype is irrelevant - the class we're extending may not even have been intended for use as a web bean. 2. Deployment-specific overriding of a certain role: we want some specific customization to a certain web bean in a certain deployment. The supertype may not have been designed with extension in mind. 3. Reuse of generic code in multiple roles: we have a generic web bean, that we customize to fill various roles in a single deployment. The supertype was probably designed for extension. In case 1, it doesn't really make sense to inherit any web beans metadata to the subtype. In cases 2 and 3, it makes sense to inherit everything that is not explicitly overridden. In case 1, observer/producer/disposal methods of the supertype should not by inherited by the subtype. In case 2, they should be inherited and should override the methods of the supertype. In case 3, they should by inherited, but should not override the methods of the supertype (and there should be special rules for deriving the binding types of producer/disposal methods). An annotation could be used to identify the reuse pattern. Presumably, case 1 should be the default. @Specializes does seem like an appropriate mechanism for handling case 2, but I'm now not so certain about the name. We have not yet finished designing a mechanism for case 3, but an annotation on either the supertype or subtype would work. So what we need now is a good terminology for cases 2/3, that helps us name the identifying annotations. Any ideas? -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

On Thu, Nov 27, 2008 at 4:09 PM, Gavin King <gavin(a)hibernate.org&gt; wrote: @Specializes and @Realizes? -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

I need to see a more realistic usecase. Why does subtypeimpl even need to decorate the method that was already decorated by basetypeimpl? Sent from my iPhone On Nov 28, 2008, at 11:50 AM, Ted Stockwell <emorning(a)yahoo.com&gt; wrote: