David Blevins wrote on 10/11/11 16:22:
> 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. :)
That was more or less the original plan. We're still working through the
details to see if there are any issues preventing us from doing that in
more/all cases. The answer isn't clear yet.
It would be helpful to have more use cases of things that don't work
currently that you think should or could work if more components were
managed beans.
> 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?
They might not be useful. Does that mean we have to write the spec to
prohibit them? I suspect there's lots of other useless things you can
do with our APIs that we don't prevent.
> 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.
That's part of what we're trying to figure out.
There's really two parts to being a managed bean:
1. What other things you can use.
2. How other things can use you.
#1 is really about how things get injected into you.
#2 is about injecting you into other things, interceptors when others call
you, etc.
Maybe the right thing is to split these concepts and declare that (e.g.)
Servlets only support #1. Is that simpler to understand? Simpler to implement?
The answer is not yet clear to me.
Think of it this way... If every technology/container/whatever that creates
a bean that is then managed were to use CDI to create that bean, and thus
automatically got all the facilities that CDI provides (injection, interceptors,
etc.), would that work?
If the web container used CDI to create the Servlet instance, thus potentially
getting a CDI-created proxy/wrapper to the real Servlet class, what problems
would that cause? If the web container calls the service method, and there's
an interceptor on the service method, would that not just work? If the
interceptor is just logging a message, that might be fine. What if the
interceptor is starting a transaction? Would it work? Or, more importantly,
would the user get the effect they expected?
If we decided we didn't want certain managed beans (e.g., servlets) to support
interceptors, but we did want them to support everything else CDI provides,
does that mean we need another way to create those managed beans that
disables interceptors? Or are these special case errors that are detected
at deployment time? How do we specify and implement the exceptions to the
general rules?
As you can see, we're still thinking through the implications of this,
so let us know more about what you think makes sense.