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@hibernate.org> wrote:
From: Gavin King <gavin@hibernate.org>
Subject: [webbeans-dev] Patterns of reuse
To: "Java Community Process JSR #299 Expert List" <JSR-299-EG@jcp.org>, "Matt Drees" <matt.drees@gmail.com>, "Scott Ferguson" <ferg@caucho.com>, "webbeans-dev@lists.jboss.org" <webbeans-dev@lists.jboss.org>
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@gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
webbeans-dev mailing list
webbeans-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/webbeans-dev
|