About that Timer API, could the newly revived Concurrency for EE JSR (236 I
believe) be of value to a new version of that? It might seem late for an
overall release train schedule, but where Enterprise users would benefit we
should consider it, regardless of the EE version it may end up in.
Am 11.04.2012 03:22 schrieb "David Blevins" <david.blevins_at_gmail.com>:
> (Happy post-JavaOne-proposal day -- we're clearly all in the same boat ;)
>
> This is a huge topic and like others I'm not sure I can put thoughts
> concretely into one of the buckets. I absolutely love the basic matrix,
> though.
>
> Before we get too far in the is conversation is it possible to get these
> matrices updated to include Transaction Management, Security and
> @Asynchronous services? I suspect they weren't added because the vision is
> that they would eventually be interceptors and therefore magically fit
> under existing terminology. If that's the case, maybe we can still add
> them with a note so we can see everything in one place.
>
> On the high level I think everyone has the exact same goal which is at
> minimum improved unity in the platform with more widely consumable services
> and at maximum complete unity in available services.
>
> I'm not sure see any way to tackle that other than to march forward one
> service at a time like we have been with @Transactional. The matrix
> definitely helps with this and one of the reasons I'd like to see
> @Transaction added so we can at least see some progress.
>
> Like with @Transactional, there will likely be revamping and modification
> going on as well as details need to be considered at each intersection in
> the matrix. I instantly fell in love with the description of Timers that
> fire CDI Events. The API then becomes timed or scheduled CDI events. The
> persistent aspect would have to be addressed and that's one example of a
> concrete detail that would need to be worked out before this could be
> added. Using the TimerService as-is also would require some things be
> addressed such the fact that we don't allow @Stateful session beans to use
> timers because there are high odds the object in question will not be
> around when the (historically persistent) timer is fired. If we exposed it
> to CDI as-is, the lifecycle (scope) of the bean would have to be taken into
> account. Off the top of my head I'd say @RequestScoped "no" and
> @ApplicationScoped "yes" wrt timers. Scopes in the middle would be up to
> debate as well as possible syntax to communicate which scopes could use
> timers. Reworking Timers to not be instance specific an instead simply
> fire events -- whoever is around to consume them, great -- is one way of
> dealing with things, but as I mention that's more an act of revamping the
> Timer API.
>
> Generic feedback on Timers: Can we make the TimerService (or a new version
> of it) a Connector? Seems to fit the bill of keeping its transactional
> nature (timers created in a transaction are not "official" till the
> transaction ends) and at the same time recasts it as a widely available
> consumable service.
>
> Seems a potential broad brush stroke is to try and define consumable
> services like timers as connectors and aspects like transactions and
> security as interceptors. Then we just have to solve "who can have
> interceptors" and "who can consume connectors" and we could be largely done
> with things at the abstract level. Who can consume connectors is already
> well defined -- everyone -- which is part of what makes it appealing.
>
> I do have a concrete question on Matrix1. There would definitely be a "Y"
> in our platform at the intersection of "Support CDI interceptors" and
> "Session beans obtained via @EJB or JNDI lookup (with CDI enabled)".
>
> I don't see how anything else is possible given an @Singleton is the same
> singleton regardless and can be referenced as both @EJB and @Inject in the
> same app.
>
> Still picking through the details of each matrix, but wanted to give at
> least some initial feedback.
>
> Worst case scenario if we do nothing with "managed bean" and continue to
> do more things like revamping apis as interceptors (and possibly
> connectors) I think it would still be a big win. Maybe the most we can
> hope for in this revision.
>
>
>
> -David
>
>
> On Mar 29, 2012, at 2:52 PM, Linda DeMichiel 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
> >
> >
> >
> >
> >
> <Matrix1.pdf><Matrix2.pdf><Matrix3.pdf><Matrix4.pdf><Matrix5.pdf><Matrix6.pdf>
>
>