jsr342-experts@javaee-spec.java.net

[jsr342-experts] ManagedBean already too broad?

From: David Blevins <david.blevins_at_gmail.com>
Date: Tue, 11 Oct 2011 16:22:14 -0700

Following up on some observations in various JavaOne panels.

A blocking concept to splitting up EJB is that @ManagedBean should apply to all the components in Java EE. So servlets, filters, and more. If I got that part wrong, this email won't be applicable. Definitely let me know if that's the case. :)


I wonder if @ManagedBean is already too odd of a fit for that purpose. Concretely, what does it mean for a @WebFilter to have interceptors? What does it mean to lookup an @WebServlet from JNDI? Are these things useful?

I have subtle shift in thinking that will be quite easy to miss, so hopefully I can express it clearly. Bear with me.

I have to wonder if simply splitting up EJB services isn't enough for a solid step forward in the evolution of the platform. Split them up and and let the other specifications adopt the services they want/need. CDI would likely adopt quite a lot of services, whereas Servlet might not adopt very many.

My gut feeling is that stating "everything is an @ManagedBean" is perhaps too aggressive and will lead us into many dead ends and awkward situations. Saying "A @WebServlet is also an @ManagedBean" likely not that useful. Does it make servlets or the platform easier to understand?

I think we had a hunch the answer might be "yes", but when it comes to actually doing the work the answer is proving more and more to be "no".

Case in point is @javax.ejb.Asynchronous. Splitting that out should be quite easy. Currently though as @ManagedBean will also mean @WebServlet, we have a lot of smart people trying to make it fit when in reality I think we all know having two asynchronous concepts on Servlets is a pretty bad idea. Yet, it's a wonderful idea for CDI and trying to pretend it isn't is a bit unnatural as well.

It sounds so tempting on the surface to say that an @ManagedBean can be a @WebServlet etc., but reality is @ManagedBean is already a logical subset of an @Stateful bean. A proxied component with interceptors and instantiate on lookup lifecycle.

There is a proposal here to create a "plain cheese" session bean http://java.net/jira/browse/EJB_SPEC-26

The obvious uptake of that proposal is we wouldn't need to create such a definition and could just use @ManagedBean instead. Pretending that @ManagedBean is not a proxied component with interceptors and instantiate on lookup lifecycle and can be an @WebFilter or @WebServlet is the part that gets us into trouble.

Do we really want that?

If we reduce the scope of @ManagedBean it just becomes so much more meaningful.


-David