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