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.