[jsr-314-open] [ADMIN] Proposal Faces Managed Bean Annotations For Containers that implement Servlet 2.5 and Beyond

[Dan Allen]

I stepped away from this thread for a few days just to establish a clear
mind and reply as such.

I feel it is important to emphasize that I was speaking from my experience
as a long time user of JSF (as I'm sure most of you are as well), who felt
the impact of these spec decisions day in and day out (and it was too often
a painful feeling). When I said that the Spring-JSF integration became the
only way to really be productive, that's what really happened on several
different projects I was involved with.

On Sun, Apr 5, 2009 at 8:28 AM, Kito Mann <kito.mann at virtua.com> wrote:

> I think the major point here is that you should be able to write a real JSF
> app without any other libraries. We are so close to that with JSF 2 -- the
> only thing missing is conversation scope.  (Managed beans are not very
> powerful, but they're good enough for some cases).


Thank you for introducing the next point I was going to make before you
replied. Can JSF stand alone? On the contrary, you cannot write a JSF app
without any other libraries. A perfect example is the EL. You cannot do JSF
without el-api.jar and el-impl.jar. So there are dependencies.

A point was raised about XML defined managed beans and where they fit. To
me, this is a backwards compatibility thing. You just have to keep them. The
quesiton becomes, do we add on to something that is "not very powerful, but
good enough for some cases" or do we try to improve the situation? Fine, you
can use @ManagedBean and that solves a marketing problem, and good for
prototypes. But it sure as heck isn't going to fix the problem my past teams
have had with these beans having a horrible dependency injection model.
That's all I'm saying.


> Furthermore, the dependency on JSP 2.1 really hurt JSF, and if we go down
> that road again, I think it's really going to hurt adoption again.


That's because JSP was living far beyond its expiration date. It's a
separate issue in my mind from what is required to use JSF.

So here's what I'm concluding. I propose we keep @ManagedBean and
@ManagedProperty to allow for quick prototyping in JSF applications and to
entice newcomers to give it a try (or upgrade). But I can tell you that from
personal experience, I will always use Seam, Guice, Spring, or Web Beans in
any production application because I can't write an mature application with
the JSF annotations alone. But that's fine, because we have a clear
migration path. If you agree, Ed, perhaps you can communicate that to the
316 EG.

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090406/bcab3762/attachment.html