That's basically what we have in Resin today :-).
On 10/26/2011 8:17 AM, Antonio Goncalves wrote:
> > 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
> <mailto: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 <http://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>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.1834 / Virus Database: 2092/4574 - Release Date: 10/25/11
>