One of the issues we're grappling with in this release is better alignment
between Java EE and CDI in the treatment of managed beans.
There has been some confusion in the community as to what a Java EE
Managed Bean is, and how Java EE Managed Beans relate to CDI.
Java EE 6 introduced the Managed Beans specification in order to
better define a spectrum of functionality applicable to Java EE
managed objects. Basic Managed Beans are container-managed objects
with minimal requirements that support a small set of basic services,
such as resource injection, lifecycle callbacks, interceptors, and the
ability to be looked up in JNDI or injected.
Modifications of the basic Managed Beans model that are allowed and
explicitly foreseen by the Managed Bean specification include:
* Other ways to declare Managed Beans
* Other ways to declare constructors of Managed Beans
* Other ways to assign a name to a Managed Bean
* Other lifecycle models
* The ability to have an own java:comp namespace
* The ability to specify other threading requirements
* The ability to have a different interceptor facility
In defining Managed Beans this way, our intention has been to
cover a spectrum of common functionalities under which to align
our component models as they evolve.
CDI managed beans are also defined very minimally: they are required
to have a no-arg constructor or a constructor annotated @Inject. (See
CDI 3.1.1 for a more precise definition).
CDI managed beans support the following functionality (not intended as
an exhaustive list): they are contextual objects, having a
well-defined lifecycle or scope that is managed by CDI; they can have
other beans and resources be injected into them; they can be injected
into other managed objects; they can have qualifiers, which support
type-safe injection; they can have interceptors, decorators, and
observer methods; they can have producer methods and producer fields,
which in turn can be sources of other managed beans.
Because CDI managed beans are defined so minimally--any class that has
a no-arg constructor can be a CDI managed bean--many of the Java EE
managed classes, in particular those listed in Table EE.5-1 of the
Java EE specification ("Component classes supporting injection"), can
be treated as CDI managed beans. Today, however, only Session Beans
retain their platform-defined component behaviors when treated as CDI
managed beans. Thus, for example, while a Servlet class (annotated
with @WebServlet) can be injected with @Inject into a CDI managed bean
or into an EJB, the instance that is injected does not have the
ability to service HTTP requests.
See the attached file Matrix1, which attempts to characterize the
managed classes of the Java EE platform with regard to CDI
functionality in a more graphic way. This is as things stand today.
Notice that while some CDI functionality that is applicable to CDI
managed beans (including sessions beans) has been extended beyond
these types, it is not extended in a uniform way. For example,
Message Driven Beans support CDI interceptors, although they don't
support the other CDI functionality that session beans do.
There is also an alignment issue within the Java EE component types
themselves (EJBs, Servlets, JAX-RS resource classes, web service
endpoints). For example, only EJBs currently and ManagedBeans support
Java EE interceptors. JAX-RS endpoints support interceptors if their
implementation class is an EJB or a ManagedBean. Web service endpoints
support interceptors if their implementation class is an EJB.
We think the current state of affairs needs clarification, and would
like to find a way to better align the notions of CDI managed bean,
Java EE Managed Bean, and Component class supporting injection.
We see several possibilities.
(1) "Do-nothing option"
Do nothing except add clarification to the Platform specification
that only EJB session bean (and, trivially, @ManagedBean) components
retain their Java EE defined component behaviors when used as CDI
(2) "First- and second- class managed objects option"
Distinguish two distinct groups of what are currently referred to
in Table EE.5.1. as "component classes": Components and auxiliary
component classes. As suggested in the earlier discussion in this
expert group, define the notion of "Component class" (used in Table
EE.5.1) more narrowly around the current component types: EJB,
Servlet, Managed Bean, and Java EE managed classes using these as
implementation types (JAX-RS resource classes and web service
endpoints). In other words, distinguish two distinct groups of what
the specification currently characterizes as "component classes":
component classes proper, and auxiliary component classes (e.g.,
filters, listeners, interceptors, ...). In addition, align the notion
of Java EE Managed Beans around container services that such types
would support (or do already support): such as container-managed
transactions, container-managed security, async invocation, and
timers/timerservice. Such services would extend also to CDI managed
beans, but Java EE components other than Session Beans and Managed
Beans would not retain their Java EE component behaviors when used as
CDI managed beans. Note that container-managed transactions,
container-managed security, and async invocation are candidates for
support via CDI interceptors. It would be desirable if we could
support timer service notifications as container-managed events using
the CDI event/observer functionality.
Matrix2 illustrates this. The blue background highlights the
changes from Matrix1. The functional change to the initial matrix is
that interceptor support would be extended to Servlets and JAX-RS
resource classes and more uniformly to EJBs and Managed Beans. (While
I've included timer support in this matrix as well, to illustrate how
these capabilities could evolve, we have no current plans to enhance
timer support in Java EE 7.)
Notice that this also removes the anomaly with regard to the treatment
of MDBs that I mentioned above. It has the disadvantage, however,
that CDI features are still not uniformly supported for Java EE components.
(2a) "Option 2 + prune the Managed Bean spec option"
Abandon the attempted generalizations of Managed Beans in Section
MB.2.2 of the Managed Beans specification, and define Java EE
ManagedBeans in terms of the "Basic Model" only. [This is the same
matrix as Matrix2.]
(3) "More CDI functionality extended into Java EE Components option"
In addition to the changes in (2), attempt to merge the notions of
Java EE Managed Beans and CDI managed beans so that the other Java EE
component types support more of the CDI functionality (i.e.,
interceptors, decorators, observer methods, producer methods/fields),
while retaining their behavior as Java EE components. An exception
here might be made for the ability to inject these into other
components while preserving their Java EE behavior. For example,
injection into other beans might be restricted to those components
that support a local view rather than remote invocation via HTTP, web
services, JMS, RMI, etc.
Matrix3 illustrates this. The green background highlights the
changes beyond Matrix2.
(4) "Injected components behave as components"
In addition to (3), Java EE components retain their component
behavior when injected. For example, the Servlet instance that would
be obtained via injection would be the same Servlet instance that the
web container was using to service HTTP requests, and similarly for the
other Java EE component types.
Matrix4 illustrates this, using the purple background to highlight
the changes beyond Matrix3.
(5) "All Java EE component classes become Java EE ManagedBeans option"
In addition to the changes in (2), extend the notion of Java EE
ManagedBean to all container managed classes in Table EE.5.1. In
addition to resource injection (which these classes already support),
they would also have lifecycle callbacks, interceptors, timer support,
and the ability to be looked up in JNDI. The functional change is
that servlet filters, listeners, interceptors, etc. would get
Matrix5 illustrates the change in functionality. The pink background
highlights the changes beyond Matrix2.
(6) "Everything is a managed bean option"
Both first- and second-class managed classes support CDI managed bean
Matrix 6 illustrates this. It includes the features of both Matrix4
and Matrix5. The yellow background highlights the addition of CDI
functionality beyond the features of Matrix4 and Matrix5.
We need your feedback!!
We realize that this is a lot of information to digest, but we really
need you to consider it all carefully and to provide your feedback.
These issues have very considerably impact on how we go forward with
managed bean support in the Java EE Platform.
[javaee-spec users] Re: [jsr342-experts] managed bean alignment