> It's all about the services and not about the "components"
I completely agree with that. EE life would be easier if there was only one
container, POJOs and a large set of services. And then a matrice showing
which service is compatible & incompatible with another service (as you
state, @WebServlet service doesn't make much sence with @Interceptor
service)
Antonio
On Wed, Oct 12, 2011 at 06:36, David Blevins <david.blevins_at_gmail.com>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
> >>
> >>
> >>
> >
>
>
--
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>