JSF 2.0 Public Review Ballot Starts Tomorrow Blog
JSF 2.0 Public Review Ballot Starts Tomorrow
Schedule as of 20090105
The public review draft ballot for JSF 2.0 starts tomorrow and voting continues until close of business Monday 12 January 2008. This means that JCP Executive Committee members are able to cast their votes on whether or not the spec can proceed from its current Public Review Draft status to being revised into a Proposed Final Draft. The meaning of this ballot is described in section 3.2 of the JCP Process Document which I excerpt here.
If the Public Draft Specification Ballot fails, the Expert Group will have 30 days to update the draft in response to the concerns raised by the EC and submit a revised version to the PMO. When the revised draft is submitted, there's another ballot called the "reconsideration ballot". If this ballot fails, the JSR will be closed and the Expert Group will disband. If the Public Draft Specification Approval Ballot (or reconsideration ballot) is successful, the Expert Group will prepare the Proposed Final Draft of the Specification by completing any revisions it deems necessary in response to comments received. EC Members may cast two types of votes: "yes" and "no". Alternatively, a Member may explicitly abstain or, in the extreme and undesirable case, not vote at all.
If you happen to have some kind of channel to one or more of the individuals on the Java EE Executive Committee, please share your thoughts with them to help inform their ballot vote. We've received a few comments to jsr-314-comments@jcp.org and also to this discussion thread but more input is always welcome. You can simply post a reply to this blog entry if you want!
On the right is a snapshot of our latest spec schedule. You can see that we're nearly done!
Technorati Tags: edburns
24 Comments
-
-
Will JSF 2.0 have same problems with JSTL like JSF 1.X with facelets? http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets //
-
@rdelaplante: Red Hat is contributing resources to work with Ed on getting the bulk of the bookmarkable URL features into 2.0 by drawing on ideas from Seam. We know how important the issue is. //
-
Ryan, you are not the only one watching the bookmarkable URL space. Seam filled it well, and I'll be extremely disappointed if it can' make it into JSF2. If JSF2 cannot prove the pundits wrong (and satisfy us defenders of JSF), then I'll definitely be looking elsewhere. Nuff said. //
-
Thank you Red Hat! The guy who wrote PrettyFaces [1] seems to think that he has done something above and beyond what Seam's boorkmarkable URLs can do. I hope they get him involved, or at least learn from his project. I know URL rewriting/pretty URLs was not planned, but I hope that makes it in as part of the HTTP GET support. http://ocpsoft.com/uncategorized/jsf-get-bookmarkable-and-pretty-urls/ //
-
Lot of community investment has gone into improving JSF and bring spec to JSF 2 level. I hope it comes out with flying colors. Bookmarkable URL, Easy Component Creation, AJAX, PDL etc are very critical. Skinning is also something which we should address in JSF 2.1(subsequent release after stable JSF 2 release). Now once we are done with JSF 2 we should quickly start discussing on JSF 3 (JSF1.2.x - to JSF 2 took years), may be something like JAVAFX widgets integrations, JAVA FX charts integration more client side (JAVA Script SandBox), better IDE support , better performace, etc.. JSF 2 seems to be very promising and future should be brighter. //
-
Mr. Delaplante, The issue for this is https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=485. I've posted your latest comment to this blog in that issue. // -
Validators are restrained to components that implements EditableValueHolder, so with components like HtmlDataTable the validators can not function, when I need validate the length of the collection that HtmlDataTable contains with a validator I can not validate that collection because validators are only valid in EditableValueHolder Components and HtmlDataTable is not an EditableValueHolder. //
-
Please improve tooling support for facelet tag libraries. Facelet tag libraries that use the library-class element, make it very hard for tools to support arbitrary namespaces. com.sun.facelets.tag.TagLibrary provides no iteration methods. We can't even tell what namespace it supports. An examination of tool support to make certain tools can minimally obtain namespaces, elements, and attributes, whenever possible, would be most appreciated. I'm referring to https://facelets.dev.java.net/nonav/docs/dev/docbook.html#taglib-create, since I did not see any specifics in the public review. //
-
-
I too hope JSF 2 migration that will start after Majorra JSF 2 stable release, will be well documented and less painful or easy. JBoss Rich Faces branch relase for JSF 2 will be an important milestone for JSF 2 adoption. //
-
Why is there a public review vote before the spec reaches final draft, and no public vote of the final draft? Public review vote ends in a couple of days and it doesn't have HTTP GET. HTTP GET isn't even on your chart, despite someone telling me that Red Hat has added extra resources to get it done. Is what they said true? That will affect my vote. Can they really start and finish that in the three weeks before proposed final draft? I would like to see someone from the EG blog about what changes are being done to state saving. //
-
I just re-read this blog entry and realized that despite being called a PUBLIC review ballot, the public cannot vote. The vote is for JCP Executive Committee members only. I hope the they are reading the comments in this post and are aware of the HTTP GET issue. //
-
It appears that nothing has been done about multi field validation: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=1 (yes ticket #1, something we've wanted forever.) Multi component validation should also be addressed in JSF 2.0. Today the only way to achieve this is to use the EditableValueHolder's getSubmittedValue method to retrieve the value of some other component while in the validator of the first component, but the javadoc warns against using that method: "This method should only be used by the encodeBegin() and/or encodeEnd() methods of this component, or its corresponding Renderer." Performing multi field validation in the action is not a viable option because it can only output FacesMessages. Actions don't have the same effect on specific components that Validators do. Wicket has had support for multi component validation since 2006: http://cwiki.apache.org/WICKET/validating-related-fields.html http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/markup/html/form/validation/EqualInputValidator.html http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/markup/html/form/validation/EqualPasswordInputValidator.html Tapestry also seems to be capable of multi-field validation: "Next, all the fields inside the form are activated to pull values out of the incoming request, validate them and (if valid) store the changes. After the fields have done their processing, the Form emits a "validate" event. This is a chance to perform cross-form validation that can't be described declaratively. Next, the Form determines if there have been any validation errors. If there have been, then the submission is considered a failure, and a "failure" event is emitted. If there have been no validation errors, then a "success" event is emitted." http://tapestry.apache.org/tapestry5/guide/validation.html //
-
HTTP GET is a MUST!! This can't be left out. This has been a complaint from day one of JSF. Years more cannot go by before this is included. I fear more people turning away from JSF if this is not part of 2.0. //
-
RD> It appears that nothing has been done about multi field validation: RD> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=1 RD> (yes ticket #1, something we've wanted forever.) Multi component RD> validation should also be addressed in JSF 2.0. Today the only way RD> to achieve this is to use the EditableValueHolder's RD> getSubmittedValue method to retrieve the value of some other RD> component while in the validator of the first component, but the RD> javadoc warns against using that method: Hello, we're looking to JSR-303 BeanValidation to help with this. In fact, Emmanuel Bernard, has been doing an excellent job and we're fully ready to include it in JSF 2.0 when the Java EE 6 platform group approves it for inclusion. Ed //
-
>>>>> On Fri, 09 Jan 2009 16:49:23 -0800, foo@bar.com said: RM> Please improve tooling support for facelet tag libraries. Facelet RM> tag libraries that use the library-class element, make it very hard RM> for tools to support arbitrary RM> namespaces. com.sun.facelets.tag.TagLibrary provides no iteration RM> methods. We can't even tell what namespace it supports. An RM> examination of tool support to make certain tools can minimally RM> obtain namespaces, elements, and attributes, whenever possible, RM> would be most appreciated. Hello Rod, thanks for the comment. We're certainly wanting it to be toolable. The combination of the composite component metadata (section 3.6.2.1) and JSR-276-Metadata, would be plenty for tools. Please make your desire for JSR-276 Metada known to its EG. jsr-276-comments@jcp.org. //
-
Ed> Hello, we're looking to JSR-303 BeanValidation to help with this. In Ed> fact, Emmanuel Bernard, has been doing an excellent job and we're fully Ed> ready to include it in JSF 2.0 when the Java EE 6 platform group Ed> approves it for inclusion. In http://forum.hibernate.org/viewtopic.php?p=2403001#2403001 Emmanuel Bernard appears to say the opposite. Apparently we're not getting multi-component validation. Note that JSR-303 does support it, but JSF doesn't seem to integrate with it (yet?). //
-
John Reynolds wrote about an interesting idea [1] where JSF's h:form tag can have validator(s) attached to it, like any other input component. The form could validate the submitted values of any combination of components using business rules, and throw a ValidatorException when there is a problem. That is how Wicket does "business form"/multi component validation [2] and it seems that this would be a simple addition to JSF 2.0 or 2.1. JSR-303 BeanValidation is definitely welcome, but I think this idea is just as important for JSF. [1] http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by_1.html [2] http://cwiki.apache.org/WICKET/validating-related-fields.html //
-
>>>>> On Thu, 22 Jan 2009 07:54:28 -0800, foo@bar.com said: RD> John Reynolds wrote about an interesting idea [1] where JSF's h:form RD> tag can have validator(s) attached to it, like any other input RD> component. The form could validate the submitted values of any RD> combination of components using business rules, and throw a RD> ValidatorException when there is a problem. That is how Wicket does RD> "business form"/multi component validation [2] and it seems that RD> this would be a simple addition to JSF 2.0 or 2.1. JSR-303 RD> BeanValidation is definitely welcome, but I think this idea is just RD> as important for JSF. We have a simple but sufficient solution to this for JSF 2.0. It's been checked in. RD> [1] http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by_1.html RD> [2] http://cwiki.apache.org/WICKET/validating-related-fields.html //
-
This is excellent. I'm glad to see multi-form validation, while it was "possible" that didn't make things "easy." Being easy, and being correct/accurate is what drives adoption :) //
-
We are working on HTTP get and I think you'll like what we come up with. Ed //
-
-
In my previous post, the Validator annotation is applied to a SFSB public method, not an entity class property or method (as is generally done with Hibernate Validator). //
392 Guest Jan 6, 2009 8:18 AM