[webbeans-dev] Drop pluggability
by Gavin King
I'm getting a bunch of feedback to the effect that the Web Beans spec
should drop the notion of a pluggable Web Bean manager.
I'm prepared to go down this path on the condition that we reach
agreement with the EE group that Web Beans will be a required part of
the Java EE 6 web profile, which is something that has not yet been
agreed (however, I believe that agreement will eventually be
achieved).
This would be a major simplifying change to the spec:
* it would immediately close off most of the open issues mentioned in
the Public Draft
* we could stop talking about a "Web Bean manager", and simply talk
about the "container", where "container" would be defined to refer to
either the Java EE container, or the embedded EJB Lite container in
the SE case
* we could remove several special cases where functionality "is not
required when a plugin Web Bean manager runs in a Java EE 5
environment"
* it would help avoid giving the impression that web beans is a
separate component model with a separate container
Of course, the downside of this change is that implementations of 299
would no longer be pluggable in different EE environments. This simply
doesn't seem like much of a big deal to me - at least not unless Web
Beans is an optional feature of EE6, in which case the pluggability
contracts are required for people to even be able to use Web Beans in
EE when their vendor does not support the optional feature.
I would like to know if anyone here is especially attached to
pluggability and would be upset by the removal of this feature. I
would especially like to know if this would affect anyone's plans to
*implement* 299.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Hierarchical Managers
by Gavin King
On the concall, we made some significant progress with the design for
hierarchical Managers. We decided to develop the following approach:
(1) web beans belonging to a child manager may have any scope
(2) each child manager has its own set of contexts (there is a
parallel context hierarchy for each scope) that "belong" to, and have
the same lifecycle as, the parent contexts
(3) therefore the web beans belonging to the child are not visible to
web beans belonging to the parent
(4) however, web beans belonging to the parent *are* visible to web
beans belonging to the child
(5) a child manager may be associated with a context by calling
Manager.setCurrent(ScopeType), and is then automagically propagated
with the context
(6) web beans belonging to the child manager may be obtained via EL
evaluation whenever the child manager is in scope, or by directly
calling a getInstance() method of the child manager
The needed API changes are as follows:
Manager {
public Manager createChild();
public void setCurrent(Class<? extends Annotation> scope);
public void validate();
}
Context {
getChild(Manager childManager);
}
There is one question remaining open:
Should it *ever* be possible to access a web bean belonging to the
child manager via a reference that was injected into a web bean
belonging to the parent manager or into some non-contextual object
such as a servlet or MDB?
For example, we might choose to support this in the case that the
child manager web bean specializes the parent manager web bean.
Bill, is this a feature that Oracle requires? If not, I'm inclined to
*not* support it in web beans 1.0.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Web Bean discovery
by Pete Muir
I was talking to Gavin about this, and he suggested that the discovery
should be more flexible and allow selectors/restrictions to be applied
to the classes discovered (for example, only abstract classes).
I can only speak about JBoss5, but I suspect this approach is common -
JBoss allows you to attach a visitor to the deployer and allows you to
do something with classes it finds (e.g. store them in some data
structure). This happens before web apps (from the Servlet listener)
starts.
The current approach is to discover the resources needed (as defined
by the spec) and store them in a datastructure, which is available
later for querying when we boot the Web Beans RI through the
ServletListener. So, the only way I can see to be more flexible is to
add the ability to apply selectors to the WebBeanDiscovery interface,
and index the classes discovered based on selectors in the jboss-
webbeans integration library. This requires us to define the selectors
we can use. We already have:
* Modifier (for discovering abstract classes)
* TYPE annotations
are there any others we are likely to need - it is better to define
these upfront before we do a release of the WebBeanDiscovery API...
16 years
[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] Patterns of reuse
by Gavin King
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
16 years
[webbeans-dev] Transactional Event Observers
by David Allen
Hi Gavin,
Nicklaus raised a good question about transaction observers (7.5.6 in
the specs): What exactly is the behavior if more than one of these
annotations is applied?
Should we not allow more than one? (Seems like the right way to go)
Or do we notify the observer for each applicable phase as requested with
the annotations?
Thanks,
David
16 years
[webbeans-dev] @Supports
by Gavin King
I've been thinking about the problem of implementing re-usable
components like our JMS endpoints. What I'm trying to do is implement
the requirements of JMS endpoints as a simple Web Bean. To do that
today, I would need to create a class which implemented all the API
types:
@ApplicationScoped
public class QueueEndpoint
implements Queue, QueueSession, QueueSender, QueueConnection { ... }
and I would have to go and implement every one of the operations of
each of those interfaces to delegate to the correct object. (A bunch
of tedious code.)
However, if we assume that the client proxy is smart enough, we could
let the Web Bean manager automagically do that delegation for us. We
would need a new annotation that could be applied to fields or
methods, for example:
@ApplicationScoped
public class QueueEndpoint {
...
@Supports Queue getQueue() { ... }
@Supports QueueSession getQueueSession() { ... }
@Supports QueueSender getQueueSender() { ... }
@Supports QueueConnection getQueueConnection() { ... }
}
We no longer need to write all those annoying delegation methods! The
client proxy would just call the correct @Supports method when the
QueueEndpoint type did not define the method that was invoked by the
client, and delegate the method to the returned object.
To make this really work, we would need to say:
* the set of API types of the Web Bean includes all types of @Supports
methods/fields
* if a certain method name appears on more than one @Supports
method/field type, it must also be implemented directly by the impl
class
* if a certain method name appears on more than one @Supports
method/field type, or on both the impl class and a @Supports
method/field type, it is always called on the impl class
Therefore, close() would need to be implemented by QueueEndpoint:
@ApplicationScoped
public class QueueEndpoint {
...
@Supports Queue getQueue() { ... }
@Supports QueueSession getQueueSession() { ... }
@Supports QueueSender getQueueSender() { ... }
@Supports QueueConnection getQueueConnection() { ... }
void close() { throw new UnsupportedOperationException(); }
}
You're probably thinking that we can do all this with @Producer
methods, however, the semantics are not exactly the same, since the
association b/w the producer object and produced object is lost as
soon as the producer method returns. Furthermore, @Producer methods
aren't really appropriate for 3rd-party reusable objects, since the
XML configuration of a producer method is verbose.
I don't believe that Web Beans 1.0 absolutely has to have this
feature, but I know its useful, and I know that we will implement it
in the RI, so I would prefer if it was portable. What do you guys
think? Useful? Too much magic? Let me know...
Seam already has an extremely primitive/braindead version of this
feature, that I've found *extremely* useful when writing reusable
components:
http://docs.jboss.com/seam/2.1.0.SP1/reference/en-US/html/concepts.html#d...
(@Factory is more or less like @Produces, whereas @Unwrap is a really
crappy version of @Supports.)
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years, 1 month
