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

[Jason Lee]

On Apr 6, 2009, at 2:51 PM, Dan Allen wrote:
> 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.

.

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


I'll grant that more complicated applications will be easier to manage
with Seam, Guice, Spring, etc, but one *can* write applications in
Plain Jane JSF, though they may be simple.  But if the user just wants
to write a simple application, then that's good enough.  We shouldn't
hamstring them, or guilt them into throwing more complex IoC solutions
into the mix just because We Know Better Than They.  FWIW, I worked at
a shop that didn't use any of the aforementioned IoC panaceas.  We
used JSF and, if necessary, EJB3.  IIRC, most were simply JSF+JPA,
which fit the bill nicely.  We weren't writing the next eBay, but they
kept that mid-size HVAC company, and continue to do so 3+ years after
some of them written.

Jason Lee, SCJP
Senior Java Developer, Sun Microsystems
Mojarra and Mojarra Scales Dev Team
https://mojarra.dev.java.net
https://scales.dev.java.net
http://blogs.steeplesoft.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090406/cf7b0388/attachment.html