jsr342-experts@javaee-spec.java.net

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

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Wed, 12 Oct 2011 20:18:42 -0400

David,

Just to be absolutely clear, my point is that we should simply create a
matrix of what standalone EJB service can be applied to what flavor of
Java EE managed bean (for a vast majority of EJB services this list will
be quite simple). I think that is ultimately what needs to be done and I
don't really see the value in adding yet another @ManagedBean. As to
JNDI registry, I think it should be kept to the bare minimum - with
@Inject it has very little practical value (in fact, in Resin we were
considering having an explicit @JndiName annotation for when it is
really needed). All the @ManagedBean annotations should really be
deprecated and managed beans treated as an "abstract" rather than
concrete concept...

Cheers,
Reza


On 10/12/2011 12:36 AM, David Blevins wrote:
> It sounds like you're somewhat in agreement. It's all about the services and not about the "components". Agreed.
>
> @Asynchronous is definitely not the edge case if @ManagedBean can be anything in Java EE. My simple point that "anything" is too broad and even "component" is not specific enough to really solve problems.
>
> - Take @WebFilter for example which is basically an interceptor. Does it make sense to allow interceptors on interceptors? Not really, but those are already part of @ManagedBean.
>
> - In EJB-land you aren't allowed to use @TransactionAttribute and @RolesAllowed in interceptors, with good reason. Would these be allowed in @WebFilters. Doesn't seem like a good idea.
>
> - @WebListener which is a callback API might benefit from @TransactionAttribute usage as @Singleton callbacks do. Would it benefit from @RolesAllowed. Not likely as there is no caller for most, if not all, of the callbacks. Do @WebListeners need interceptors? Iffy at best.
>
> - Do @WebServlets need interceptors? Perhaps interesting. One could argue it's either really cool or really confusing.
>
> - Do we actually want to enforce that all "components" in Java EE have global JNDI names including all servlets, and CDI beans?
>
> Of course all the services above apply quite nicely to a proxied object model which is where they were born, outside that model usefulness is really on a case by case basis. If we define @ManagedBean as a proxied component model it can be a great help in splitting up the services at least for CDI and EJB purposes which are proxied object models. These split services can of course be used in the various specifications where applicable as decided by those specifications.
>
> If we stretch @ManagedBean too far it seems like we quickly create an unsolvable problem where useful things can't be split out because they don't apply to "everything". We'll end up with fewer split services than more split services with that approach.
>
>
> -David
>
>
> On Oct 11, 2011, at 6:45 PM, Reza Rahman wrote:
>
>> David,
>>
>> I basically commented on this on the JIRA issue, but will add some more detail here:
>>
>> The basic managed bean concept in Java EE 6 (aside from the actual physical @ManagedBean annotation and the baggage that goes along with it) was designed to form a common component model for all Java EE components (e.g. life-cycle callbacks, injection, interceptors). I think it serves that purpose extremely well and is very promising in improving further ease-of-use for Java EE in a similar fashion that Spring, Guice, Seam (without EJB), etc have enjoyed for a while now. As to the @ManagedBean annotation itself, it serves little practical purpose for most Java EE 6 end users and really should be deprecated (as should the same annotation in JSF). It's still entirely a mystery to me as to why @ManagedBean needs a JNDI name beyond making the old/limited @Resource annotation to work instead of just focusing on getting @Inject right throughout the platform...
>>
>> In practice, the large majority of EJB services are very applicable to any Java EE managed bean, including Servlets. @Asynchronous might basically be the only exception. I think it basically repeats the EJB 1/2-ish mistakes of the past to start from that corner case and overgeneralize with the final result of yet another redundant/confusing component level annotation symbolizing yet another needless "container" that is of little practical use to the end user. I think the more sensible route is to simply exclude the services that are not right for a given Java EE component model (e.g. perhaps detecting these issues at deployment time).
>>
>> In this case, I really do think being too slow to evolve to meet market realities is holding Java EE adoption in general back. No matter what we do, it all comes back to the awkward and redundant plethora of mutually incompatible component models we seem to continue to insist on having in Java EE and I'm not sure why that is...
>>
>> Cheers,
>> Reza
>>
>>
>> On 10/11/2011 7:22 PM, David Blevins wrote:
>>> 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
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1831 / Virus Database: 2090/4545 - Release Date: 10/10/11
>>>
>>>
>>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1831 / Virus Database: 2090/4547 - Release Date: 10/11/11
>
>
>