Hi Markus,
Thanks for the feedback. More below....
On 4/10/2012 3:23 AM, Markus Eisele wrote:
> Hi Linda,
> hi all,
>
> First of all: thanks to Linda for your efforts and explanations. That
> was a bundle ;)
> Sorry for the late reply, it took some time thinking this over and
> getting my thoughts together here.
>
>> 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.
>
> First of all I would like to state, that I expected that to happen, too.
> While doing EE 6 projects I didn't came across a single occasion where
> this has been a real trouble. What causes headache is the fact that all
> the Managed Beans have different capabilities.
> I like Antonio's view on Managed Beans a lot and I second his thoughts.
>
>> incompatibilities between thess services. I really think that the final goal
>> should be : one container, one POJO, many services.
>
> This would also solve a lot of problems with the different
> responsibilities for the
> component models. Looking at Linda's matrix and possible solutions I was asking
> myself where to put the definition (and responsibilities) for the
> different managed-beans.
> Having a 1:1 relation container:bean and defining a set of services
> which are mandatory
> for specific containers we also support a common definition across the
> specifications.
>
> And another point in favor of Antonio's proposal is the situation we
> have with JSF.
> To me especially the third type of Managed Bean we have in the
> platform causes confusion for the users.
> (JIRA discussion reference
> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-976)
> As to Ed's comment the "annotations from the appropriate Java EE
> specification should be used in preference to these".
> And he is not going to remove/deprecate them shortly. Why? Mojarra is
> still capable of running outside of a Java EE compatible server
> (Tomcat).
> So they are willing to keep their own implementation of both the
> component model and the behavior.
>
> I would go for (6) "Everything is a managed bean option" as fast as possible.
>
Just to be sure, what does "everything" include in your view?
In particular, does it include all of the classes shown as having scope in Matrix 6?
thanks,
-Linda
> -M
>
> On 10 April 2012 10:11, 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 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 | Twitter | Blog | LinkedIn | Paris JUG