Ed Burns's Blog

New Drafts of Java EE Web Tier: JSF 1.2, JSP 2.1, Servlet 2.5

I'm pleased to announce another revision of the Java EE Web Tier. In Jan Luehe's blog you can find out what's new in JSP 2.1 Proposed Final Draft 2 (PFD2). The Change Log for Servlet 2.5 will give you the scoop on the Servlet spec. This blog entry will show what's new in the JSF spec.

In JSF, the most visible new feature since the last draft of the spec is the addition of the invokeOnComponent() method on UIComponent. See below for more details.

This revision of the Java Web Tier is fully implemented in glassfish build 37, Sun's open source Java EE 5 Application Server, and the basis for the upcoming Java EE SDK.

Spec changes since PFD, chronologically by section number

• 9.5: The TLDDocs for the h: and f: taglibs are now a normative part of the spec.

• 5.4: Use of JSR-250 Common Annotations @PostConstruct and @PreDestroy for managed bean lifecycle notifications. See my August 2005 blog entry for more on this feature.

• 3.1.10: Specify how EL ValueExpressions must me handled in the attributes map returned from UIComponent.getAttributes().

• 5.4: List the supported Java EE 5 annotations one may put in a JSF Managed bean.

  
  @Resource
  @Resources
  @EJB
  @EJBs
  @WebServiceRef
  @WebServiceRefs
  @PersistenceContext
  @PersistenceContexts
  @PersistenceUnit
  @PersistenceUnits
  

• 2.2.2: Define the term "local value" more concretely.

• Preface: Added section on backwards compatibility with previous versions of the JSF spec.

• 9.4.8: Explicitly state that the use and meaning of a UIParameter child is the responsibility of the parent component inside which it is nested.

• 5.3: State that managed bean properties may be Java enum types. Define coercion rules.

• 7.1.1: Widen the expected type returned from a UICommand action method to be Object instead of String. This allows the use of Java enum types as returns from action methods, which can simplify navigation rules.

• 7.3: State that the Action method must return Object.

• 3.1.8: New method: UIComponent.invokeOnComponent(), and supporting callback interface ContextCallback. This method allows you to execute a callback on an arbitrary node in the view given its clientId. An override is provided for UIData that provides for correctly positioning the table to the proper row before continuing to find the component.

• 9.3.1.2: Add a note mentioning that tld-version in an explicit taglib def, and version in an implicit taglib def are semantically equivalent with respect to their use in determining the backwards compatability strategy employed.

JSF-API Contract Changes, chronological by functional area

• Standard HTML RenderKit: Changes to outputText, outputFormat, message and messages renderers. Add header and footer facets to the declaration of UIColumn. Specify that the default value of the "rendered" property is true. The "target" attribute of the link renderers is not a passthru attribute. Modify commandLink renderer to describe what should happen if "disabled" is true. Attributes that have a boolean value or meaning, such as "ismap", "disabled", or "readonly", must be rendered without attribute minization. For example, "ismap=ismap". Update "acceptcharset" attribute on Form to be non-passthrough since the attribute value is rendered as "accept-charset". GridRenderer supports the "caption" attribute.

• Wrappers for decorating StateManager, ViewHandler, and ResponseWriter.

• JSP Custom tags for JSF 1.2 Components must now extend javax.faces.webapp.UIComponentELTag. JSF 1.1 component tags still extend UIComponentTag, which is now deprecated.

• The prependId property of UIForm is now ValueExpression enabled.

• New method on UIComponent, invokeOnComponent and new callback interface ContextCallback.

• Relax the spec language for findComponent to allow for any implementation that accomplishes the same thing as the specified algorithm. Also allow for findComponent to work properly if nested naming containers with the same name exist.

JSF-API Implementation Changes, chronological by functional area

• Refactored build system to be more maintainable.

• Rob Gibson contributed a fix to improve how more than one JSF portlet may run in the same portal.

• Performance improvements in attribute/property transparency.

• Modify FacesServlet so that if the servlet is prefix mapped, requests starting with WEB-INF or META-INF must return SC_NOT_FOUND.

• Changes to make tree creation and content interweaving work with jsp:include and JSTL's c:import.

• Changed all @exception javadoc statements to @throws statements due to Sun bug 6359046.

• Allow UIParameter children inside of select* components.

• Various backwards compatibility allowances.

Comments

• Can we please include portlets in JEE5?!
  .V

  Posted by: netsql on February 19, 2006 at 06:01 PM

• Hello Ed,
  This looks quite nice for JSF, ok maybe I am a bit biaised because of "Enum" and "action" update the the introduction of genericity (yeah !!!) ;-)

  But the "big question remains" for other spec about the use of genericity in the same way. An example of that is the latest Servlet spec (2.5MR2) that is still does not genericity friendly AFAIK. Do you know if servlet's leader plan to integrate this for 2.5 ?

  JSP and JSF generification still to be doubl-cjecked as doing a quick check on JSP I've found an example of non-generified method: getAttributeNamesInScope on JSPScope ... should I push such issues to the spec feedback mail or to any other site ? Plz, let me know.

  As you've understood my mantra is : « having Java EE 5 ignoring the major language feature of Java SE 5 is "bad"(tm)» so let's generify-them-all ;-)

  By the way doing "deeper" genericity for JSF 2.0 could be also a "good thing"(tm) ... but I agree that focus is now on doing "simple things".

  Rgs,
  Jean-Baptiste

  Posted by: bjb on February 21, 2006 at 04:08 AM

• All sounds really great. But is the issue of not being able to add rows to dataTable/dataModel's and have them successfully rendered, when scoping a bean to request ever going to be delbt with?

  I know there are solutions like ADF's processScope, your suggestion of introducing a RoR flash scope and myface's t:saveState. But is there not possibility that this will fall under the umbrella of the spec itself?

  Seems as this should be supported and most JSF does indeed maintain request attributes between requests. There is also a redirect attribute for navigation rules, so this sort of thing is already implied, it just hasn't never worked (in 1.0, 1.1 and now 1.2).

  With standalone tiles and shale filling in a few gaps (shale-validator for example), I can see no reason not to adopt jsf (jsp model n all) over struts. But needing to scope to session for this sort of thing is too fundamental to justify such a move.

  To solve this I've been trying phase listeners to get in the middle of where things get lost, to no avail. If there's a way then any suggestions would be appeciated as a simple phase listener approach in theory would be a nice way of solving this.

  Its a shame cos everything else I've been trying out on glassfish is really cool.

  Mark

  Posted by: melowe on February 27, 2006 at 08:45 AM

• Hello Ed.
  I read your interesting article "Web Tier to Go With Java EE 5: Summary of New Features in JavaServer Faces 1.2 Technology" on java.sun.com.
  I'm wondering about flexibility of new validatorMessage attribute.
  Using validatorMessage attribute of UIInput components with multiple (and probably of different type) registered Validator components, all unsuccessfull validations return the same message as specified in validatorMessage attribute.
  I agree that validatorMessage attribute solution is useful to customize messages for different UIInput components using the same Validator, but it lacks flexibility when you have multiple Validators for an UIInput and want different validation messages.
  I know that multiple validators / one UIInput is uncommon and that it's more common multiple UIInput / one validator pattern (promote reuse of validators). Perhaps a more general solution could be the possibility to specify different messages for different validator types using a child tag like <f:validatorMessage validator="javax.faces.Length" value="My message for LengthValidator" /> (it's very uncommon to use multiple validator of the same type).

  Mauro

  Posted by: mauro_castaldo on March 05, 2006 at 03:26 AM

• Hi, Ed! I have some EL-related questions. I asked Jacob Hookom about them, but I would appreciate your opinion as well. I have trouble understanding some ideas behind Unified EL in JSP 2.1. The discussion is here. Thanks!

  Posted by: michael_jouravlev on March 08, 2006 at 06:46 PM

• Mark,

  
  ML>All sounds really great. But is the issue of not being able to add
  ML>rows to dataTable/dataModel's and have them successfully rendered,
  ML>when scoping a bean to request ever going to be delbt with?

  ML>I know there are solutions like ADF's processScope, your suggestion of
  ML>introducing a RoR flash scope and myface's t:saveState. But is there
  ML>not possibility that this will fall under the umbrella of the spec
  ML>itself?

  Yes, I agree this is important, and should be in the next spec version.
  In the meantime, I've suggested that the MyFaces impl team and the Sun
  JSF Impl team coordinate and build a defacto standard for the Flash, or
  something like it. We'll see how that goes.

  Ed

  Posted by: edburns on March 09, 2006 at 12:19 PM

• 
  M> I read your interesting article "Web Tier to Go With Java EE 5:
  M> Summary of New Features in JavaServer Faces 1.2 Technology" on
  M> java.sun.com.

  Actually, that article was written by Jennifer Ball, who is also the
  force behind the JSF content in the Java EE
  Tutorial.

  
  M> I'm wondering about flexibility of new validatorMessage
  M> attribute. Using validatorMessage attribute of UIInput components
  M> with multiple (and probably of different type) registered Validator
  M> components, all unsuccessfull validations return the same message as
  M> specified in validatorMessage attribute. I agree that
  M> validatorMessage attribute solution is useful to customize messages
  M> for different UIInput components using the same Validator, but it
  M> lacks flexibility when you have multiple Validators for an UIInput
  M> and want different validation messages.

  M> I know that multiple validators / one UIInput is uncommon and that it's
  M> more common multiple UIInput / one validator pattern (promote reuse
  M> of validators). Perhaps a more general solution could be the
  M> possibility to specify different messages for different validator
  M> types using a child tag like

  
  

  In Fact, we did have something just like that in earlier drafts of
  the spec, but we went with the simple attribute because we believed it
  satisfied the 80% case. Let me see what the EG thinks of your
  suggestion. It's a small change with positive impact.

  M> (it's very uncommon to use multiple validator of the same type).

  Ed (JSF co-spec-lead)

  Posted by: edburns on March 09, 2006 at 12:28 PM

This work is licensed under a Creative Commons License.