Hi Dan, No offense taken although I'm going to remove my EG member hat to answer that from personal point of view only, not involving Fujitsu's. Firstly, from my experience and the conferences I've given, JSR-299 is not what I would call a rock star in people mind. In fact, I feel that it may be extremely unpopular. That status started a short thread in the past where Kito proposed that JSF provides its own conversation scope in case 299 didn't live up to the expectation and, to be honest, I kind of agree with him. I would have liked a page flow scope at least out-of-the-box in JSF for wizard based applications. So, my first reason is I don't think people will use JSR-299 much (at least at first), while, as you mentioned, JSF 2.0 is probably one of the most awaited spec of JEE 6 (if not the most). Secondly, depending on JEE 6 means that people won't be able to run JSF 2.0 outside JEE 6 application servers, placing us in the same situation as with JSF 1.2's dependency on JSP 2.1, meaning JSF 2.0 won't be used for about 2 years from now which is not an incredibly interesting marketing statement considering all the most needed improvements (especially with interoperability) that 2.0 brings. Regards, ~ Simon ________________________________ From: JSR 314 Open Mailing list on behalf of Dan Allen Sent: Fri 4/3/2009 3:30 PM To: JSR-314-OPEN(a)JCP.ORG Subject: Re: [ADMIN] Proposal Faces Managed Bean Annotations For Containers that implement Servlet 2.5 and Beyond At one time there were criticisms that JSR-299 was not addressing the problem it set out to solve, which was to create a solid integration between JSF and EJB through the use of annotations inspired by Seam and similar initiatives. But to me, the problem is not with JSR-299 but with JSF 2.0 not acknowleging the solution being proposed in the JSR-299 spec. I've yet to understand why JSF is trying to define it's own annotations for name-to-bean mapping when that is the role of JSR-299 (the beans themselves could be EJB or this "simple bean" whereever that is going to end up living). I know a lot of effort has gone into creating these managed bean annotations for JSF 2.0, but that doesn't remove the fact that they are duplicates of what JSR-299 has. Besides, I really can't see being very productive with the still limited dependency injection that the managed bean annotations offer. Having to reference a value expression only in @ManagedProperty seems really awkward to me (and always has even from JSF 1 days, which is why I always used Spring). I'm saying this not to upset anyone but to point out that we need to make sure that these specs actually look they considered one another. And why is it such a big deal that JSF 2 rely on Java EE 6? How long are we really talking about in the grand scheme of things? People have waited so long for JSF 2 that we might as well get the best integration we can rather than fudge and confuse users as to when they can use what parts. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com <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.

Simon et. al. I'm specifically avoiding (for the obvious reason that I am extremely biased) taking a stance here, however I would like to emphasize, that, although the JSR-299 spec is tied to Java EE, there are implementations that run (or intend to run) in pretty much any environment: * the RI currently runs in JBoss, GlassFish, Tomcat and plain Java SE * I know from talking to people from the Apache OpenWebBeans team that they have similar goals in terms of targets (and have actually been concentrating on servlet containers for now). On 4 Apr 2009, at 19:24, Simon Lessard wrote: > Hi Dan, > > No offense taken although I'm going to remove my EG member hat to > answer that from personal point of view only, not involving > Fujitsu's. > > Firstly, from my experience and the conferences I've given, JSR-299 > is not what I would call a rock star in people mind. In fact, I > feel that it may be extremely unpopular. That status started a > short thread in the past where Kito proposed that JSF provides its > own conversation scope in case 299 didn't live up to the > expectation and, to be honest, I kind of agree with him. I would > have liked a page flow scope at least out-of-the-box in JSF for > wizard based applications. So, my first reason is I don't think > people will use JSR-299 much (at least at first), while, as you > mentioned, JSF 2.0 is probably one of the most awaited spec of JEE > 6 (if not the most). > > Secondly, depending on JEE 6 means that people won't be able to run > JSF 2.0 outside JEE 6 application servers, placing us in the same > situation as with JSF 1.2's dependency on JSP 2.1, meaning JSF 2.0 > won't be used for about 2 years from now which is not an incredibly > interesting marketing statement considering all the most needed > improvements (especially with interoperability) that 2.0 brings. > > > Regards, > > ~ Simon > > > ________________________________ > > From: JSR 314 Open Mailing list on behalf of Dan Allen > Sent: Fri 4/3/2009 3:30 PM > To: JSR-314-OPEN(a)JCP.ORG > Subject: Re: [ADMIN] Proposal Faces Managed Bean Annotations For > Containers that implement Servlet 2.5 and Beyond > > > At one time there were criticisms that JSR-299 was not addressing > the problem it set out to solve, which was to create a solid > integration between JSF and EJB through the use of annotations > inspired by Seam and similar initiatives. But to me, the problem is > not with JSR-299 but with JSF 2.0 not acknowleging the solution > being proposed in the JSR-299 spec. I've yet to understand why JSF > is trying to define it's own annotations for name-to-bean mapping > when that is the role of JSR-299 (the beans themselves could be EJB > or this "simple bean" whereever that is going to end up living). > > I know a lot of effort has gone into creating these managed bean > annotations for JSF 2.0, but that doesn't remove the fact that they > are duplicates of what JSR-299 has. Besides, I really can't see > being very productive with the still limited dependency injection > that the managed bean annotations offer. Having to reference a > value expression only in @ManagedProperty seems really awkward to > me (and always has even from JSF 1 days, which is why I always used > Spring). > > I'm saying this not to upset anyone but to point out that we need > to make sure that these specs actually look they considered one > another. And why is it such a big deal that JSF 2 rely on Java EE > 6? How long are we really talking about in the grand scheme of > things? People have waited so long for JSF 2 that we might as well > get the best integration we can rather than fudge and confuse users > as to when they can use what parts. > > -Dan > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > > http://mojavelinux.com <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. -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete

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). 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. I'm not at all convinced that the Java EE vendors won't take another 1-2 years to implement Java EE 6. Also, so far we've been telling everyone this will run on Java EE 5. Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Apr 5, 2009, at 12:12 AM, Pete Muir <pmuir(a)REDHAT.COM&gt; wrote: > Simon et. al. > > I'm specifically avoiding (for the obvious reason that I am > extremely biased) taking a stance here, however I would like to > emphasize, that, although the JSR-299 spec is tied to Java EE, > there are implementations that run (or intend to run) in pretty > much any environment: > > * the RI currently runs in JBoss, GlassFish, Tomcat and plain Java SE > * I know from talking to people from the Apache OpenWebBeans team > that they have similar goals in terms of targets (and have actually > been concentrating on servlet containers for now). > > On 4 Apr 2009, at 19:24, Simon Lessard wrote: > >> Hi Dan, >> >> No offense taken although I'm going to remove my EG member hat to >> answer that from personal point of view only, not involving >> Fujitsu's. >> >> Firstly, from my experience and the conferences I've given, >> JSR-299 is not what I would call a rock star in people mind. In >> fact, I feel that it may be extremely unpopular. That status >> started a short thread in the past where Kito proposed that JSF >> provides its own conversation scope in case 299 didn't live up to >> the expectation and, to be honest, I kind of agree with him. I >> would have liked a page flow scope at least out-of-the-box in JSF >> for wizard based applications. So, my first reason is I don't >> think people will use JSR-299 much (at least at first), while, as >> you mentioned, JSF 2.0 is probably one of the most awaited spec of >> JEE 6 (if not the most). >> >> Secondly, depending on JEE 6 means that people won't be able to >> run JSF 2.0 outside JEE 6 application servers, placing us in the >> same situation as with JSF 1.2's dependency on JSP 2.1, meaning >> JSF 2.0 won't be used for about 2 years from now which is not an >> incredibly interesting marketing statement considering all the >> most needed improvements (especially with interoperability) that >> 2.0 brings. >> >> >> Regards, >> >> ~ Simon >> >> >> ________________________________ >> >> From: JSR 314 Open Mailing list on behalf of Dan Allen >> Sent: Fri 4/3/2009 3:30 PM >> To: JSR-314-OPEN(a)JCP.ORG >> Subject: Re: [ADMIN] Proposal Faces Managed Bean Annotations For >> Containers that implement Servlet 2.5 and Beyond >> >> >> At one time there were criticisms that JSR-299 was not addressing >> the problem it set out to solve, which was to create a solid >> integration between JSF and EJB through the use of annotations >> inspired by Seam and similar initiatives. But to me, the problem >> is not with JSR-299 but with JSF 2.0 not acknowleging the solution >> being proposed in the JSR-299 spec. I've yet to understand why JSF >> is trying to define it's own annotations for name-to-bean mapping >> when that is the role of JSR-299 (the beans themselves could be >> EJB or this "simple bean" whereever that is going to end up living). >> >> I know a lot of effort has gone into creating these managed bean >> annotations for JSF 2.0, but that doesn't remove the fact that >> they are duplicates of what JSR-299 has. Besides, I really can't >> see being very productive with the still limited dependency >> injection that the managed bean annotations offer. Having to >> reference a value expression only in @ManagedProperty seems really >> awkward to me (and always has even from JSF 1 days, which is why I >> always used Spring). >> >> I'm saying this not to upset anyone but to point out that we need >> to make sure that these specs actually look they considered one >> another. And why is it such a big deal that JSF 2 rely on Java EE >> 6? How long are we really talking about in the grand scheme of >> things? People have waited so long for JSF 2 that we might as well >> get the best integration we can rather than fudge and confuse >> users as to when they can use what parts. >> >> -Dan >> >> -- >> Dan Allen >> Senior Software Engineer, Red Hat | Author of Seam in Action >> >> http://mojavelinux.com <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. > > -- > Pete Muir > http://www.seamframework.org > http://in.relation.to/Bloggers/Pete

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.

The problem I have with this viewpoint is that if you take standalone JSF and compare it to the myriad of alternatives the developer has to choose from, many of the alternatives are much more attractive. Basically, if it were that simple of an application, I might not even use JSF (Grials perhaps). I might not even use Java EE.

I just don't understand why we are trying to keep an arms length distance from Java EE (whether it be 5 or 6). JSF *is* a part of Java EE. It's value is not in a standalone framework. We can let it be used standalone, just like JPA, but that should be secondary to the tight integrations it offers with Java EE. We have to be realistic about what else is available to developers.

Leave the annotations in for the simple cases, and leverage the EE6 stuff for the more complex. There's no good technical reason to throw away the "low end" applications. I would choose another word for "complex", perhaps "sophisticated" or "refined". Other than that, I think we are in agreement as to the scope of each option. I suggest we add non-normative text in the spec that recommends for a complete DI and context management solution, developers should be forward looking to JCDI. Of course, we can't say when it will be available, but surely containers will start offering it as a backport as Web Beans is doing. It's refreshing to me, as an application developer, to know that a mature DI and context management solution is going to be available without having to go outside of Java EE (e.g., Spring) to get it. While we want to appeal to the entry-level users with @ManagedBean and @ManagedProperty, we should also assure those more advanced users that we have considered their needs as well. Hence the recommendation for the non-normative text. -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.