[webbeans-dev] Stereotype inheritance proposal
by Gavin King
I've got feedback from a number of people that stereotype inheritance
should be supported, and I agree with this feedback.
I think we should just do it in the simplest possible way and say
simply that stereotype declarations are transitive, and
meta-stereotypes are inherited by the web bean.
Therefore:
1. the sets of interceptor binding types are unioned
2. any conflicts between default scope/deployment type defined by a
stereotype and its meta-stereotypes must be resolved by explicit
declaration on the web bean
3. all restrictions apply cumulatively
And I've written this into section 2.7.1.5 of the attached spec draft.
Questions:
========
Does anybody think that the default scope/deployment type declared
directly by a stereotype should *override* the default
scopes/deployment types declared by its meta-stereotypes? This rule
makes a lot of sense, but it kinda makes things a little more complex.
For example:
@RequestScoped
@Stereotype
public @interface Foo {}
@SessionScoped
@Foo
@Stereotype
public @interface Bar {}
Should we force a web bean that declares @Bar to explicitly specify a
scope, or is it better to let @SessionScoped on Bar override
@RequestScoped on Foo.
Another thing I've just noticed, that applies to interceptor bindings
inherited by both stereotypes and other interceptor binding types, is
that you could potentially have a web bean with multiple "instances"
of the same interceptor binding type - the same type, but different
member values. I think we should say that this is a
DefinitionException.
For example:
@Transactional(requiresNew=false)
@Stereotype
public @interface Foo {}
@Transactional(requiresNew=true)
@Stereotype
public @interface Foo {}
@Foo @Bar
public class X {}
Then X has both @Transactional(requiresNew=false) and
@Transactional(requiresNew=true).
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Terminology
by Gavin King
I've had a few discussions with a certain EE vendor who is concerned
that the use of the "Bean" terminology sends the message that Web
Beans is a separate component model that competes with EJB. I don't
necessarily agree, but I can see why some people might get that
impression. Whatever: on this issue I think we should do whatever is
necessary to make 299 palatable to all the vendors in the space.
So we should search for alternative terminology. Here's my suggestion:
Web Bean -> injectable type
simple Web Bean -> injectable java class
enterprise Web Bean -> session bean
Web Bean instance -> injectable instance / instance of an injectable type
WDYT? Does anyone have a better suggestion? Does anyone *not* want to
make this change?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Fwd: Patterns of reuse
by Gavin King
Folks, please read this first draft of chapter 4.
---------- Forwarded message ----------
From: Gavin King <gavin(a)hibernate.org>
Date: Tue, Dec 2, 2008 at 5:26 PM
Subject: Re: Patterns of reuse
To: Java Community Process JSR #299 Expert List <JSR-299-EG(a)jcp.org>
OK, here's a draft of the new Chapter 4 that implements this idea.
Please read this over and let me know what you think!
On Tue, Dec 2, 2008 at 2:26 PM, Gavin King <gavin(a)hibernate.org> wrote:
> So, after talking this over with Jason, we're inclined to think that
> we should rely on the use of the @Inherited annotation in
> java.lang.annotation to control inheritance of type-level metadata:
>
> * scope
> * deployment type
> * binding types
> * name
> * stereotypes
> * type-level interceptor bindings
>
> For annotations defined by the spec, we would say that:
>
> * all built-in scope types are declared @Inherited
> * no built-in binding type is declared @Inherited
> * @Name is not declared @Inherited
> * no built-in stereotype is declared @Inherited
>
> There are four scenarios of metadata inheritance in the spec today:
>
> * implementation class inheritance
> * XML configuration
> * stereotype transitivity
> * interceptor binding type transitivity
>
> I think @Inherited is definitely a good way of controlling metadata
> inheritance in the cases of implementation class inheritance and XML
> configuration. For example, if we have the following types:
>
> @MyStereotype
> class Foo { ... }
>
> class Bar extends Foo { .... }
>
> then it seems completely natural to me that we would decide whether
> @MyStereotype is inherited by Bar on the basis of whether it is
> declared @Inherited. Likewise, it seems natural in the case of XML
> configuration:
>
> <myapp:Foo>
> ...
> </myapp:Foo>
>
> The big question in my mind is whether it is also appropriate to use
> this mechanism to control transitivity of metadata declared by
> stereotypes, for example, suppose that @MyStereotype declares
> @MyOtherStereotype:
>
> @MyOtherStereotype
> @Stereotype
> ...
> public @interface MyStereotype { ... }
>
> And @MyOtherStereotype declares a deployment type:
>
> @Staging
> @Stereotype
> ...
> public @interface MyOtherStereotype { ... }
>
> Should we look at the @Inherited annotation to decide if @Staging is
> inherited by @MyStereotype? I'm thinking that the answer is "no", but
> I'm not sure.
>
> Of course, we still need to define "special" rules for the
> member-level metadata:
>
> * method-level interceptor bindings
> * initializer methods + injected fields
> * producer/disposal
> * observer methods
>
> Does all that make sense?
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Fwd: Patterns of reuse
by Gavin King
FYI
---------- Forwarded message ----------
From: Jason T. Greene <jason.greene(a)redhat.com>
Date: Tue, Dec 2, 2008 at 11:37 AM
Subject: Re: Patterns of reuse
To: JSR-299-EG(a)jcp.org
Gavin King wrote:
-snip=
> Let's categorize them:
>
> Things that probably should never inherit:
> * deployment type
>
> Things that probably should always inherit:
> * scope
> * stereotypes
> * initializer methods + injected fields
> * type-level interceptor bindings
> * method-level interceptor bindings
An interesting problem with this is that stereotypes can reference
deployment types. If stereotypes are allowed to be inherited, what
happens to the referenced deployment type? Is it ignored?
--
Jason T. Greene
JBoss, a division of Red Hat
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Fwd: Patterns of reuse
by Gavin King
FYI
---------- Forwarded message ----------
From: Gavin King <gavin(a)hibernate.org>
Date: Tue, Dec 2, 2008 at 2:26 PM
Subject: Re: Patterns of reuse
To: Java Community Process JSR #299 Expert List <JSR-299-EG(a)jcp.org>
So, after talking this over with Jason, we're inclined to think that
we should rely on the use of the @Inherited annotation in
java.lang.annotation to control inheritance of type-level metadata:
* scope
* deployment type
* binding types
* name
* stereotypes
* type-level interceptor bindings
For annotations defined by the spec, we would say that:
* all built-in scope types are declared @Inherited
* no built-in binding type is declared @Inherited
* @Name is not declared @Inherited
* no built-in stereotype is declared @Inherited
There are four scenarios of metadata inheritance in the spec today:
* implementation class inheritance
* XML configuration
* stereotype transitivity
* interceptor binding type transitivity
I think @Inherited is definitely a good way of controlling metadata
inheritance in the cases of implementation class inheritance and XML
configuration. For example, if we have the following types:
@MyStereotype
class Foo { ... }
class Bar extends Foo { .... }
then it seems completely natural to me that we would decide whether
@MyStereotype is inherited by Bar on the basis of whether it is
declared @Inherited. Likewise, it seems natural in the case of XML
configuration:
<myapp:Foo>
...
</myapp:Foo>
The big question in my mind is whether it is also appropriate to use
this mechanism to control transitivity of metadata declared by
stereotypes, for example, suppose that @MyStereotype declares
@MyOtherStereotype:
@MyOtherStereotype
@Stereotype
...
public @interface MyStereotype { ... }
And @MyOtherStereotype declares a deployment type:
@Staging
@Stereotype
...
public @interface MyOtherStereotype { ... }
Should we look at the @Inherited annotation to decide if @Staging is
inherited by @MyStereotype? I'm thinking that the answer is "no", but
I'm not sure.
Of course, we still need to define "special" rules for the
member-level metadata:
* method-level interceptor bindings
* initializer methods + injected fields
* producer/disposal
* observer methods
Does all that make sense?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Fwd: Patterns of reuse
by Gavin King
FYI
On Sun, Nov 30, 2008 at 3:11 PM, Evan Ireland <eireland(a)sybase.com> wrote:
> When you wrote:
>
>> 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.
>
> Why would a supertype define web beans meta data if it is not intended
> for use as a web bean, as well as it is not intended for subtypes to
> inherit the meta data?
>
> Frankly, I think that ALL meta data should be inherited by default, unless a
> meta data item is specially marked as not being inherit
Well, ok let's discuss this.
First let's get clear what we are talking about here. These are the
kinds of metadata that exist:
* scope
* deployment type
* binding types
* name
* stereotypes
* type-level interceptor bindings
* method-level interceptor bindings
* initializer methods + injected fields
* producer/disposal/observer methods
Let's categorize them:
Things that probably should never inherit:
* deployment type
Things that probably should always inherit:
* scope
* stereotypes
* initializer methods + injected fields
* type-level interceptor bindings
* method-level interceptor bindings
Things that should only inherit in specialization case:
* binding types
* name
Things that only inherit in specialization and realization cases, with
"special" semantics:
* producer/disposal/observer methods
Does that classification make sense?
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] JSR-227
by Nicklas Karlsson
Hi,
Noticed that JSR-227 (Data binding) had popped up as an closing early
draft. JSR-227 is mentioned briefly in the original
JSR-299 request as a goal in the form "Ensure that the component model
can be used with JSR-227 databinding." Is there any
technical requirements etc for JSR-227 and Web Beans interoperability
or is just "separate layer, will work automgically"?
---
Nik
16 years
