Skip to main content

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

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr342-experts@..., Antonio Goncalves <antonio.goncalves@...>
  • Subject: [javaee-spec users] [jsr342-experts] Re: managed bean alignment
  • Date: Wed, 11 Apr 2012 17:00:24 -0700
  • List-id: <jsr342-experts.javaee-spec.java.net>
  • Organization: Oracle Corporation

Hi Antonio,

On 4/10/2012 1:11 AM, Antonio Goncalves wrote:
Hi all,

In my point of view Java EE should just define services and incompatibilities 
between thess services. I really think
that the final goal should be : one container, one POJO, many services.  I 
don't know if we all agree on this and if
it's something we should have in mind for future releases of Java EE.

ManagedBeans used broadly in all the components because they define too many 
services : as you mentioned Linda, not all
components have interception, not all components have injection. ManagedBean should be 
just seen like "markup interface"
: everything in Java EE is managed by a container (or a provider), so 
everything is a managed bean. That's it. A managed
bean does not have any specific services (otherwise this service should be 
applied to every component, which is not the
case today). Even entities could be seen as managed bean like this.

Attached is a an example of what I would like to see in the future of Java EE 
:

* Incompatibility services matrix.pdf : There are so many services in EE that 
having a single matrix is not possible.
The Java EE spec should list all these services and each spec should then 
explain how to aggregate these services
* Stereotype.pdf : why not using CDI stereotypes to aggregate these services 
into well known annotation : @Stateless ==
RequestScoped + Injection + Injectable + Security + Transaction + Poolable

"one container, one POJO, many services (optionally aggregated into 
stereotypes)" is not easy to do in only one version
of Java EE, so maybe we could start with Matrix 6 (and go further in Java EE 
8) : everything is a managed bean this way
we have a common base to start


I guess I'm not clear on what you're proposing given your services matrix and 
my matrix 6.
In matrix 6, "auxiliary" classes such as filters, interceptors, decorators... 
are all
managed beans.  Was it your intent that these be injectable/scoped/contextual 
objects
or are they an aspect of what you are characterizing as services?

regards,

-Linda

Antonio


On Fri, Apr 6, 2012 at 23:58, Linda DeMichiel <linda.demichiel@... 
<mailto:linda.demichiel@...>> wrote:

    Thanks for the input. This is a helpful start to the discussion.
    More inline below....


    On 4/5/2012 5:50 PM, reza_rahman@... <mailto:reza_rahman@...> wrote:

        Firstly, I am glad we are finally getting to this very critical 
issue. Secondly, thanks for doing such a
        thorough job analyzing this.

        This is an issue we've discussed extensively and repeatedly at Caucho 
and hence I can offer what I think is a
        fairly well thought out opinion. Unfortunately, it can't be as simple 
as picking one of the matrices. I hope
        you'll forgive me and try to find a way of reconciling what I have 
below:

        * Java EE Managed Beans:
        We found that the @ManagedBean annotation is actually a source of 
confusion/frustration for most developers. I
        think it's best to gradually prune this annotation or simply leave it 
be. The overall concept is very good
        though and definitely should be kept around. The way we look at it, 
the fundamental concept serves as the
        unifying component model whereas all the other Java EE APIs can add 
their own services, including CDI. The basic
        question then really becomes which Java EE services are "legal" to be 
used on the very same managed bean. You
        could think of this as a kind of "service compatibility" matrix, in a 
much similar vein to yours.


    Right.  This is what we want expert group input on!  How should such
    services be expanded?  Which of the current JavaEE/EJB services should
    be extended to CDI "managed beans"?  What of the CDI functionalities
    should be made available to which Java EE managed objects?  To move
    forward we need more feedback from the group on the specifics.


        * @Resource, @EJB:
        These two annotations are largely redundant with CDI. It's best to 
gradually prune these annotations or simply
        leave them be. We should try to find a way of merging whatever 
remaining functionality they have with CDI.


    Could you expand further as to how you see @Resource being redundant?
    @Resource also functions as a means to specify the binding of a logical 
resource
    to the actual resource in the environment.  How would you see this 
happening
    in the absence of @Resource in CDI?


        * Java EE interceptors:
        These were a fairly hasty and poor attempt at addressing 
cross-cutting concerns. It's best to gradually prune
        this or simply leave them be and focus on CDI annotations. 
Alternatively, perhaps CDI annotations should be
        merged back with this (harder to do I think).


    Our opinion has been that we should leverage the CDI interceptor
    capabilities more broadly, as we proposed with the use of
    transactional interceptors.  Again, in the attempt to be more
    concrete, our matrices illustrate the possible extents to which the
    use of interceptors might be expanded.  For example, as noted in my
    writeup, we would also like to explore leveraging CDI interceptors as
    a more general mechanism to provide "container-managed" security.
    We've also been discussing with the Bean Validation and CDI specleads
    how CDI interceptors might be leveraged as a mechanism to provide
    method-level validation.


        * EJBs:
        There are few valid reasons left for EJB to continue to have it's own 
component model. It increases the learning
        curve for new developers and has always proven to be a sticking point 
for Java EE adoption.  It's best to
        gradually prune this or simply leave them be. As you suggested, let's 
separate the very useful EJB services from
        the component model and make them usable in managed beans as much as possible, 
likely as CDI "system" interceptors.


    Yes.  This separation is what we are suggesting -- the migration of
    container-managed services that EJB currently provides to other
    component types via a more generalized alignment around the notions of
    managed beans and interception.  If we are successful in this, then
    yes, we will eventually have faded away much of the need for EJB per se.
    Again,  the devil is in the details.  Remember too though that our pruning
    process is designed not to leave customers behind as we evolve our 
technology.


        * JSF:
        JSF managed beans and scopes are a set of endless confusion for Java 
EE developers. It's best to gradually prune
        these or simply leave them be and find ways to better merge JSF with 
CDI. It's also very embarrassing that
        things like JSF converters and filters don't support injection, etc.


    I'll let the JSF spec lead follow up on this one.....


        * JAX-RS:
        JAX-RS doesn't really need a lot of special treatment. You can 
probably place JAX-RS annotations on managed
        beans of various flavors. It's probably also OK i most cases for 
JAX-RS annotated managed beans to be injectable
        (into other components) as well. Some of this probably applies to 
JAX-WS as well.


    If they are injectable, what should the semantics be?  Do they still
    function as JAX-RS resource classes for incoming HTTP requests?  Ditto
    JAX-WS.


        * Servlet:
        Similar to JAX-RS, Servlet related components probably don't need 
much special treatment either other than the
        fact that it makes little sense to make them injectable.


    See my comments below regarding the differences between matrix 3 and
    matrix 4.  Why does it not make sense for servlets to be injectable
    but JAX-RS and JAX-WS endpoints?


        * JPA:
        As I've mentioned in the past, we should seriously consider ways of 
making JPA entities just another managed
        bean with full access to things like injection. This is really pretty 
crucial if Java EE is to fully support
        DDD. Spring enables this today already and it is a source of 
competitive advantage.


    Could you be more specific here?  What would it mean for a JPA entity
    to be a contextual object?  You should feel free to raise the issue of
    injection into JPA entities in the JPA expert group and/or file an
    RFE there so that we can track as something to consider in a future
    release.


        * Bean Validation:
        This is really the right model that other Java EE APIs could try and 
emulate. It has little in terms of it's own
        component model/life-cycle but just defines annotation based 
services/SPIs that can be placed on any candidate
        managed bean. We should see if bean validation can be even better 
incorporated to JAX-RS and the like.

        I hope this makes sense and helps. I am happy to explain anything 
further or try to help formulate concrete
        proposals.


    It does -- we appreciate your sharing your perspectives.  It would
    be helpful if you could also comment specifically on some of the
    issues raised in my email below as to some of the potential steps that
    we might consider with regard to specific functionality.

    thanks again,

    -Linda



        Mar 29, 2012 05:53:14 PM, jsr342-experts@javaee-spec.__java.net 
<mailto:jsr342-experts@...> 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 <http://www.antoniogoncalves.org> | Twitter 
<http://twitter.com/agoncal> | Blog
<http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn 
<http://www.linkedin.com/in/agoncal> | Paris JUG
<http://www.parisjug.org>


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

reza_rahman@... 04/06/2012

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

Werner Keil 04/06/2012

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

Reza Rahman 04/11/2012

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

Linda DeMichiel 04/11/2012

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

Linda DeMichiel 04/06/2012

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

Antonio Goncalves 04/10/2012

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

Werner Keil 04/10/2012

Message not available

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

Markus Eisele 04/10/2012

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

Linda DeMichiel 04/12/2012

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

Linda DeMichiel 04/12/2012

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

Reza Rahman 04/11/2012

<Possible follow-up(s)>

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

Pete Muir 04/10/2012

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

David Blevins 04/11/2012

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

Pete Muir 04/11/2012

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

Werner Keil 04/11/2012

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

Linda DeMichiel 04/11/2012

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

Linda DeMichiel 04/18/2012
 
 
Close
loading
Please Confirm
Close