jsr342-experts@javaee-spec.java.net

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

From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
Date: Sat, 29 Oct 2011 08:29:00 +0200

Hi,

My concern is not about ManagedBean being too broad or not (same concern can
be applied to EJBs, Servlets and so on), it's more about having created a
new component model. Java EE has a lot of historical background, one of them
being "components". In the first releases it maybe made sense (EJBs were
components, Servlets too) but today it's confusing : is a POJO a component ?
Is an EJB a POJO ?

Java EE is getting easier for developers and they are starting to embrace it
again. To keep it even simpler, I really think we should get rid of the
concept of component. Everything should be POJOs being managed by a single
container (no more EJB container vs Web container, that's confusing too) on
which we apply services (tx, security, concurrency...).

If we don't want to get rid of ManagedBean, let's make it a stereotype
bundling 3 services (lifecycle, injection, interception), same thing for
@Staless wich could be seen as another sterotype with different services
(lifecycle, injection, interception, tx, security, concurrency...). But at
least we give the developper to choose which services he/she needs, and if
the set of services matches an existing stereotype, then fine, let's keep
@ManagedBean, @EJB, @WebServlet and so on.

For me the formula should be : POJOs + Set of services + One container
managing it all

My 2 cents
Antonio

On Wed, Oct 26, 2011 at 21:00, Linda DeMichiel
<linda.demichiel_at_oracle.com>wrote:

> Thanks for the feedback.
>
> David has raised a number of key points that need to be considered.
>
> I'd like to get feedback from more of the members of the group here.
>
> -Linda
>
>
> On 10/23/2011 10:13 AM, Pete Muir wrote:
>
>> 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
>>>> http://java.net/jira/browse/**EJB_SPEC-26<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.
>>>
>>
>> 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.
>>>
>>
>>
>>


-- 
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>