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_at_lycos.com <mailto:reza_rahman_at_lycos.com>" <reza_rahman_at_lycos.com
> <mailto:reza_rahman_at_lycos.com>>:
>
> 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_at_javaee-spec.java.net <mailto: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
>
>
>