Skip to main content

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

  • From: Linda DeMichiel <linda.demichiel@...>
  • To: jsr342-experts@..., Werner Keil <werner.keil@...>
  • Subject: [javaee-spec users] [jsr342-experts] Re: managed bean alignment
  • Date: Wed, 11 Apr 2012 14:13:24 -0700
  • List-id: <jsr342-experts.javaee-spec.java.net>
  • Organization: Oracle Corporation



On 4/6/2012 2:18 AM, Werner Keil wrote:
Reza/all,

Thanks for this detailed analysis and listing those items.

If you say "leave be" do you mean leave redundant to other, possibly better 
options for backward compatibility?
Unless one of those must remain for backward compatibility in apps and containers I 
would as you said "merge" them and
remove from the new specs.


These need to remain for backward compatibility, at least for quite some time.

I should note also that our "pruning" process is intended for more coarsely 
grained functionality--
see the spec section on pruning and also the reference to 
https://blogs.oracle.com/mr/entry/removing_features
which defines the process.


Regarding Bean Validation, note, there's more to come, should Java 8 include 
JSR 308.
Similar to what we saw with e.g. JSF or CDI and the ManagedBean concept, 
checkers for 308 are all over the place and
several, especially @NotNull, @NonNull or many other variations have spawned. 
Only waiting to create confusion and mayhem.
I'd say it is mostly up to BV Spec Lead on those, but where a set of built in 
standard annotations for EE or future SE
versions (then again affecting us no later than EE8) is also part of this 
discussion, I guess it is subject to the EE
EG, too.

Regards,
Werner

Am 06.04.2012 02:50 schrieb "reza_rahman@... <mailto:reza_rahman@...>" 
<reza_rahman@...
<mailto:reza_rahman@...>>:

    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.

    * @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.

    * 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).

    * 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.

    * 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.

    * 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.

    * 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.

    * 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.

    * 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.


    Mar 29, 2012 05:53:14 PM, jsr342-experts@... <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





[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
 
 
Close
loading
Please Confirm
Close