I stepped away from this thread for a few days just to establish a clear mind and reply as such.<br><br>I feel it is important to emphasize that I was speaking from my experience as a long time user of JSF (as I&#39;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&#39;s what really happened on several different projects I was involved with.<br>
<br><div class="gmail_quote">On Sun, Apr 5, 2009 at 8:28 AM, Kito Mann <span dir="ltr">&lt;<a href="mailto:kito.mann@virtua.com">kito.mann@virtua.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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&#39;re good enough for some cases).</blockquote>
<div><br>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.<br>
<br>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 &quot;not very powerful, but good enough for some cases&quot; 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&#39;t going to fix the problem my past teams have had with these beans having a horrible dependency injection model. That&#39;s all I&#39;m saying.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Furthermore, the dependency on JSP 2.1 really hurt JSF, and if we go down that road again, I think it&#39;s really going to hurt adoption again.</blockquote><div><br>That&#39;s because JSP was living far beyond its expiration date. It&#39;s a separate issue in my mind from what is required to use JSF.<br>
<br>So here&#39;s what I&#39;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&#39;t write an mature application with the JSF annotations alone. But that&#39;s fine, because we have a clear migration path. If you agree, Ed, perhaps you can communicate that to the 316 EG.<br>
<br>-Dan<br></div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don&#39;t hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters.  Please don&#39;t hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>