jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: managed bean alignment

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 10 Apr 2012 10:22:58 +0200

Hi Antonio/all,

Thanks for the detailed information.

Have we ever used JIRA for any of those items, or intend to?
A few of your bullet points and items in the attachment do sound worthy of
that, assuming anybody uses it.

-- 
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* TUGDK: Apr 26 2012, Copenhagen, Denmark. Werner Keil, JCP EC Member,
Java Social
Project Lead will talk about "Social Media Extensions for Typo3"
* geecon: May 16 2012, PoznaƄ, Poland. Werner Keil, JCP EC Member,  Java Social
Project Lead will present "Java EE 7"
* JustJava: May 18 2012, Sao Paulo, Brazil. Werner Keil, JCP EC Member,
Java Social Project Lead will present "Java Social"
* Dutch Mobile Conference: June 7-9 2012, Amsterdam, Netherlands. Werner
Keil, JCP EC Member, OpenDDR Evangelist will present "OpenDDR"
On Tue, Apr 10, 2012 at 10:11 AM, Antonio Goncalves <
antonio.goncalves_at_gmail.com> 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
>
> Antonio
>
>
> On Fri, Apr 6, 2012 at 23:58, Linda DeMichiel <linda.demichiel_at_oracle.com>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_at_lycos.com 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_at_javaee-spec.**java.net<jsr342-experts_at_javaee-spec.java.net>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>
>