Jeremy,<br><br>Thanks for your excellent reply. I'm excited because I see a common thread emerging in our exchange and, with some clarifications on my part, I think we can arrive at a compatible message. Let me state the message, then get into the inline responses.<br>
<br>The JSF EG is in the business of creating a UI component model specification. That's complex enough on it's own. A programming model is equally complex and better solved by existing solutions. (JSR-299 took 3 years to work it out and Spring has been around twice that long).<br>
<br>If the developer wants to target a native Java EE technology stack, we should consider recommending platform managed beans (@javax.annotation.ManagedBean) with CDI services. If the developer's scope is broader, then we could suggest for them to consider alternative bean containers such as Spring. It's even possible to recommend the use of @javax.annotation.ManagedBean with @javax.inject.Inject to have a bean which is portable to both Java EE and Spring, likely the ideal recommendation for setting a common ground.<br>
<br>Hopefully we can all agree that it's time to look past the rudimentary JSF managed bean facility. I don't think we do anyone a service by showing them the @javax.faces.ManagedBean in examples because it's just not going to stand up to the long-term challenges the developer is going to face.<br>
<br>I'll now jump inline to provide clarifications of my earlier statements to help support this neutral position.<br><br><div class="gmail_quote">
On Fri, Dec 18, 2009 at 9:08 PM, Jeremy Grelle <span dir="ltr"><<a href="mailto:Jeremy.Grelle@springsource.com" target="_blank">Jeremy.Grelle@springsource.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
First off, I agree that the ultimate goal of pointing users away from the JSF-managed bean model is a good thing.</blockquote><div><br>Great!<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That said, we (myself and Keith along with the rest of the Spring team whom we represent) have our reservations about CDI. So while I agree that the ultimate goal is a good one, I just want to be clear that I am slightly wary of this getting turned around and becoming a public statement of, "The JSF EG thinks you should use CDI." If some of the members of the EG want to individually make that push, that's their right, just as it is ours to say we don't see a great benefit to choosing CDI over Spring. What I would really like to see is us figuring out the most possible common ground between CDI and Spring when showing examples that are alternative to the JSF managed bean facility.<br>
</blockquote><div><br>Absolutely. I think if the goal is to demonstrate a common ground solution, then a @javax.annotation.ManagedBean with @javax.inject.Inject is the way to go. If the presentation or demonstration has either a more Java EE-centric theme or a more Spring-centric theme, then naturally the recommendation can swing to the respective side.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I really want to make it clear that we don't see it as an "us vs. them" thing when talking about Spring and Java EE on the whole.</blockquote><div><br>Great! And neither do I. I think that we all work hard to offer developers good strong choices and I want to continue to learn from each other. The representatives from the various JSF component libraries set a nice example for how collaboration, rather than contests, strengthen the whole ecosystem.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Spring has always provided first-class integration with a wide range of the individual parts of EE, and we continue to do so with EE 6 beyond just JSF 2 as evidenced by our support of specs like JSR-330, JPA 2, Bean Validation, javax.annotation.ManagedBean, etc. in the recently finalized Spring 3.0.</blockquote>
<div><br>What's important here is it respects the developer's time spent learning this programming model and we can leverage that common thread in the case when we want to show compatible programming model in a JSF 2 example.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The major difference being that we enable the use of these pieces in a completely modular and portable way that is just as powerful in a lightweight servlet container like Tomcat as it is in a full-blown commercial app server like WebSphere or WebLogic. The benefits are evidenced by the fact that you can easily use many of these EE 6 pieces *today* with Spring 3.0 even in a container like WebSphere 6.1 that is still quite widely deployed and is only J2EE 1.4 compliant.<br>
</blockquote><div><br>The point you make here is one of the driving forces for Weld to provide the CDI environment for a Servlet Container. We also recognize that you sometimes have to cater to what is out there, and to provide lightweight solutions. My hope is that Java EE will continue to become more modular, but the Web Profile is certainly a step in that direction.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm getting off-topic, but I just want to make the point that we are not anti-EE 6.<br></blockquote><div><br>Great! And I can share with you personally that when I recommend Java EE 6, it's because I see the potential in that platform, not because I'm anti-Spring.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> When JSF was created, no other facility was available for defining contextual managed beans. As of Java EE 6, there is now a platform-wide definition of a managed bean.<br>
<br>
</div>I assume you mean javax.annotation.ManagedBean, right? As I mentioned, we do support this in Spring 3.0. I believe this, as well as the other shared annotations such as @Resource, @PersistenceContext, @Inject, etc. could be our best common ground to use when showing JSF 2 examples.<br>
</blockquote><div><br>Yes, @javax.annotation.ManagedBean. Excellent. I'm excited we've been able to find this common groud.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> With the services of CDI, there is a way to discover, produce, scope, inject, name and override beans. All of a sudden, the injection facility, and limited number of services in the JSF managed bean facility looks rudimentary in comparison. And the reality is, before CDI, most developers likely used an alternative bean container anyway (probably Spring) to define managed beans. So the JSF managed bean facility has been falling out of favor for a long time.<br>
<br>
</div>Right, but are you saying we should all tell developers to use CDI instead of Spring now even if they are already happily using Spring?</blockquote><div><br>Not at all. I didn't mean to imply that developers should drop a solution they are happy with. As I said, many JSF 2 developers probably already have Spring in there.<br>
<br> What I'm advocating is for JSF to step away from solving the managed bean problem, and for us to downplay the existing facility. JSF once had a responsbility to provide a managed bean container or else it wouldn't have worked in the Java EE platform. It needed to provide something so that it could be shipped with Java EE. Now, the managed bean spec and the CDI services is present to close that gap, relieving JSF of this responsibility.<br>
<br>So, when the context of a tutorial is the native Java EE platform, it's appropriate to show @javax.annotation.ManagedBean (with CDI) over the JSF managed bean facility. If the tutorial has a broader scope, then any backend container (Spring included) is certainly appropriate to demonstrate/recommend.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I just don't see CDI being a clearly better alternative to Spring (in fact, I see the opposite, but I freely admit to being biased in that regard), and I don't know that we should have an opinion either way collectively as an EG. Again, individual opinions will vary as to which one to choose, but as a group it seems we should generally remain agnostic, especially if our overall goal is to get as many people as possible to be successful with JSF 2.<br>
</blockquote><div><br>+1 to not having to establish a collective opinion, other than to say it is not JSF managed beans.<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;">
<div><br>
> But there is a more serious problem with continuing to recommend the use of the JSF managed bean facility. The injections do not take the scope of the injected bean into consideration. That means, you cannot inject a request-scoped bean into a session-scoped bean without causing the request-scoped bean to become a session-scoped bean through attachment. This is a very typical occurance with having managed beans in a web application. CDI not only keeps beans in different scopes loosely coupled, it hides the scope at the injection point.<br>
<br>
</div>I'd just like to point out again for the sake of contrast that Spring 3.0 supports the same sort of approach quite well. We of course supported this previously with our "scoped-proxy" feature since back in Spring 2.0, but it had to be configured per-bean and was thus only slightly less annoying than configuring JSF managed beans. JSF was a major part of the use case for making it work "by default" with annotation-based configuration without having to do extra work.<br>
</blockquote><div><br>Yep, which backs up my statement that the JSF managed bean facility simply isn't cutting it anymore.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> But I won't be able to use CDI in a Servlet Container, right?<br>
><br>
> Not true. The CDI reference implementation (Weld) provides a single extension JAR (weld-servlet.jar) that you drop into your web application archive and you get a full CDI environment (you just don't get EJBs, but that's to be expected).<br>
<br>
</div>And by proxy you also don't get declarative transaction support, correct? To me, that's an immediate show-stopper for any non-trivial application vs. what you get with Spring in a servlet container.<br></blockquote>
<div><br>Touche. I agree that a gap was left behind. The @TransactionAttribute annotation (in addition to some other EJB features) should have been allowed on platform managed beans. We plan to support this in Weld as a prototype for a revision of the platform. I won't deny that there is still work to be done in making the Java EE programming model truly excellent. But we can all improve, right?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Isn't CDI just a Red Hat thing?<br>
><br>
> Of course not. We should all be behind CDI. As the spec lead, Red Hat worked very hard to define a set of services for Java EE managed beans that would make the development of enterprise applications simpler. That's exactly the type of effort we all put in for the JSF 2 specification. (JSF 2 was forged by all of us collectively. CDI has the same story). So CDI is your technology, one that you can use in Java EE 6 or even outside of it. There is no reason to back away from it.<br>
<br>
</div>With all due respect, I still fail to see why we should *all* be behind CDI.<br></blockquote><div><br>Let me clarify the context here. When I used the term *all* here, I was thinking in the context of folks advocating the native Java EE platform, not all of the JSF EG, per se. If you are presenting on JSF 2 running in the context of native Java EE 6, you should be prefering CDI beans over the @javax.faces.ManagedBean without hesitation. As I said before, if you are presenting a broader view, then certainly consider any and all available backends and choose one based on merit.<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;">
<div><br>
> Perhaps a lot of the heated debating over dependency injection turned you off, but that heated debate really made the whole platform better because EG members, like us, talked and worked things out in the end.<br>
<br>
</div>Actually, what turns me off is that what we ended up with seems to only be partially worked out and is still a bit of a mess, to be perfectly blunt. I'll elaborate more on that in my discussion of the examples below.<br>
<div><br>
> @ManagedBean<br>
> @RequestScoped<br>
> public class BlogEditor {<br>
> @ManagedProperty("#{blogDao}") BlogDao blogDao;<br>
> // getters and setters required<br>
> }<br>
<br>
</div>First off, I assume these (including @ManagedBean) are all from the javax.faces.bean set of annotations.</blockquote><div><br>Yes.<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;">
Agreed, in this particular example, I would not recommend this approach. What about @ViewScoped though? That's one of the more useful pieces of JSF 2 in my opinion. I don't believe there is an out-of-the-box CDI-equivalent, right? I would assume it's not hard to implement a custom @ViewScoped that CDI would recognize?<br>
</blockquote><div><br>There isn't a CDI equivalent of @ViewScoped in the CDI spec, but Weld/Seam will be providing a portable extension, hopefully getting weaved back into a revision of the spec. We shouldn't have to revert to @javax.faces.ManagedBean just to get this feature.<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;">
<div><br>
> We want to show them:<br>
><br>
> @Named<br>
> @RequestScoped<br>
> public class BlogEditor {<br>
> @Inject BlogDao blogDao;<br>
> }<br>
<br>
</div>So first of all, I think it would be great if we'd ended up with something like the above that would "just work" in both CDI and Spring. But we didn't. We do actually support the use of @Named as a class-level annotation like this in Spring 3.0. But I'm curious, why in CDI do you recommend using @Named vs. javax.annotation.ManagedBean? It seems to me like @ManagedBean has more clearly defined semantics at the class-level.<br>
</blockquote><div><br>I actually share this view with you, but I didn't have the ability to influence an alignment. As it turns out, @Named is a synonym for @ManagedBean, so we could recommend the latter in our common ground scenario.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Then we're back to the problem of the scopes. We of course support various scope annotations in Spring, and support something equivalent to your above example, but don't specifically support the CDI scope annotations. What really has me a bit confused is why the CDI scopes don't use @Scope from JSR-330 and instead use the JSR-299-specific @NormalScope. The JSF scopes don't either, for that matter, but I assume that's because 330 was finalized well after. See, this is what I mean by it being a bit of a mess. We've got some JSF-specific scopes, we've got CDI-specific scopes, we've got Spring-specific scopes, etc. Spring can and will ultimately support the equivalent of all of the useful ones (including @ConversationScoped in the near future...I really wish we could have just relied on JSF or CDI for that), but it sadly seems like we ended up with more fragmentation rather than less.<br>
</blockquote><div><br>I'll admit that I don't know the story behind the choice to not align the scope annotations. And already we are hearing from developers that having the javax.faces.* stuff in there is adding to the confusion. That's why, to start, we need to get that stuff deprecated. Then, I think, we should figure out how to get the number of duplicate scopes down to one. I encourage you guys to pursue this goal over on the JSR-299 EG. The only way this is going to get resolved is if communication happens. We can't really solve that problem here.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
So in the above example, we at least have @Named and @Inject as commonly supported things. I really wish there were one common, complete and portable set of scope annotations we could support in Spring, but there isn't.<br>
</blockquote><div><br>The one consolation is that the semantics are exactly the same. A scope is a scope and it's defined on the bean class. So we have to fudge this around for now, but again, as long as we are staying away from @javax.faces we are heading in the right direction.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> I'm asking you to consider my request to get behind CDI.<br>
<br>
</div>I'm perfectly fine with a world where CDI and Spring co-exist peacefully.</blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Despite my own misgivings about CDI, I acknowledge that it appeals to some. The goal of moving away from the JSF managed bean is a good one.</blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But as the collective EG whose goal is to see as much adoption as possible of JSF 2, and given the corporate realities of how soon most people are going to be using an EE 6 container, I don't see how we can be asked to promote it as *the* choice of the EG.<br>
</blockquote><div><br>This has been a great discussion. I think what we can agree on is what we don't recommend, the JSF managed bean container. What we can both get behind is a common set of annotations to hook into stronger bean containers such platform managed beans + CDI or platform managed bean annotations with Spring. @javax.annotation.ManagedBean + @javax.injectInject and do what you can to find a common ground for scopes ;)<br>
<br>I'm glad that we can communicate with friendly exchanges and I always
look forward to getting your perspective. Frankly, I think that's what
defines this EG, as Andy so elegantly pointed out in his blog.<br><br>-Dan</div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><br>