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