[javaee-spec users] [jsr342-experts] Re: managed bean alignment

From: Antonio Goncalves <>
Date: Mon, 17 Sep 2012 15:19:52 +0200

Hi all,

I'm bringing this topic back. In the EJB spec ML we've talked about
aligning EJBs with Bean Validation. For us having method-level validation
in EJBs sounds natural. It looks like method-level validation will also
happen in JAX-RS. But what about JAX-WS ? Servlets ? JMS ? I expect being
able to use method-level validation in the entire platform (it would be
weird to have it in JAX-RS but not in JAX-WS for example).

For the moment a ManabedBean gives 3 services (injection, interception and
life-cycle). What about adding method-level validation ?


On Wed, Apr 18, 2012 at 10:14 PM, Linda DeMichiel <> wrote:

> Hi all,
> We *really* would like to get more feedback from all of you on this
> issue. It would be most helpful if you could reply as specifically
> as possible to the items outlined below.
> thanks,
> -Linda
> On 3/29/2012 2:52 PM, Linda DeMichiel wrote:
>> 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
>> managed beans.
>> (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
>> these features.
>> 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
>> capabilities.
>> 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.
>> thanks,
>> -Linda

Antonio Goncalves
Software architect and Java Champion
Web site <> |
LinkedIn <> | Paris
JUG<> |
Devoxx France <>