Ed Burns's Blog

JSF 2.0 Public Review Ballot Starts Tomorrow

JSF 2.0 Public Review Ballot Starts Tomorrow

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

Comments

• In the thread you linked to you wrote: "Bookmarkable URLs, we'll see. Looking doubtful at this point."

  I will vote NO on JSF 2.0 if you don't include HTTP GET. This should have been one of the top priorities in JSF 2.0. I've emailed the expert group several times asking about this, and emailed some members directly. Nobody will respond. This is not good communication from the JCP, and now it looks like they are dropping the #1 feature JSF developers want!

  It doesn't matter how great of a job you've done on Ajax and EZComp features if we can't have fundamental basic web framework features like bookmarkable URLs! If JSF 2.0 doesn't have built-in support HTTP GET then I and many others who've been hanging in there waiting for 2.0 will finally give some serious thought about moving to Wicket, Tapestry or Struts 2.

  Posted by: rdelaplante on January 05, 2009 at 10:18 PM

• 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

  Posted by: bigmartin on January 06, 2009 at 07:49 AM

• @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.

  Posted by: mojavelinux on January 06, 2009 at 03:52 PM

• 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.

  Posted by: damatrix on January 07, 2009 at 04:46 AM

• 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/

  Posted by: rdelaplante on January 07, 2009 at 12:17 PM

• 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.

  Posted by: rahul_maha on January 08, 2009 at 01:55 AM

• 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.

  Posted by: edburns on January 08, 2009 at 07:11 AM

• 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.

  Posted by: leonardoavs on January 08, 2009 at 07:43 AM

• 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.
  

  Posted by: rodmagnuson on January 09, 2009 at 04:49 PM

• @edburns: Excellent, thank you. I'm really looking forward to JSF 2.0 and HTTP GET support. Hopefully with pretty URLs/url rewriting like in Seam and PrettyFaces too.

  BTW, the Rich Faces team says that they are working on a cleaned up JSF 2.0 version:
  http://www.jboss.com/?module=bb&op=viewtopic&t=146232
  

  Posted by: rdelaplante on January 09, 2009 at 06:04 PM

• 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.

  Posted by: rahul_maha on January 09, 2009 at 11:28 PM

• 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.

  Posted by: rdelaplante on January 10, 2009 at 08:34 AM

• 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.

  Posted by: rdelaplante on January 10, 2009 at 08:43 AM

• 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

  Posted by: rdelaplante on January 10, 2009 at 09:30 AM

• 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.

  Posted by: kurzweil4 on January 13, 2009 at 09:28 PM

• 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

  Posted by: edburns on January 21, 2009 at 09:27 AM

• >>>>> 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.

  Posted by: edburns on January 21, 2009 at 09:39 AM

• 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?).

  Posted by: fromage on January 22, 2009 at 06:31 AM

• 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

  Posted by: rdelaplante on January 22, 2009 at 07:54 AM

• >>>>> 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
  

  Posted by: edburns on February 05, 2009 at 11:56 AM

• 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 :)

  Posted by: lincolnbaxter on February 06, 2009 at 08:37 AM

• We are working on HTTP get and I think you'll like what we come up with.

  Ed

  Posted by: edburns on February 06, 2009 at 12:25 PM

• If you're not using Seam (, e.g.) then I would say that HTTP GET would be very necessary.

  Also, Seam has a @Validator annotation which makes business validations much easier to handle. I'm talking about use cases which require a db read to determine if the value entered in a inputText is already in a table or not (dynamically onblur and also onsubmit of the form).

  In these cases, with Seam apps, you can't use a custom Hibernate Validator b/c it exists outside of the Seam lifecycle and will not necessarily behave as expected and reliably.

  There is a valueChangeListener attribute in JSF but I'm not sure if it works as well as the Seam Validator.

  Posted by: rabies on February 07, 2009 at 09:19 AM

• 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).

  Posted by: rabies on February 07, 2009 at 09:20 AM

This work is licensed under a Creative Commons License.