[javaee-spec users] Re: ManagedBean already too broad?

From: Pete Muir <>
Date: Sun, 23 Oct 2011 18:13:54 +0100

Sorry for the delay on this, I thought my messages were getting through but on talking to Linda, it appears they never arrived ;-)

On 13 Oct 2011, at 03:09, Bill Shannon wrote:

> 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
>> 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.

I think it's simpler. This is what CDI does. It has the concept of a "contextual instance" - something that is injected itself, and can be injected into other beans. It also has a "non-contextual instance" - something that is injected itself, but isn't injected into anything else. CDI also says that interceptors are only applied to contextual instances (primarily as it doesn't control the creation of non-contextual instances).

The naming of this stuff is a bit obscure, but the split works well.

I think this makes managed beans considerably more useful.

> 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?

This would be very nice. I think CDI would need minimal changes to support this model (more just around the wording of stuff, not the concepts or detail).

> 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?

Personally, I would make these things "non-contextual" as a general rule - no interceptors. Some might want to be contextual in odd circumstances.

> 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?

I don't think so. We can add a concept to the CDI spec that allows you to have a non-contextual instance with or without interceptors. And an API to support this. Should be pretty easy to specify and implement (flick a switch basically)

> 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.