Skip to main content

(Updated) JavaServer Faces 1.2 and JavaServer Pages 2.1 Proposed Final Draft Specifications available

Posted by edburns on August 25, 2005 at 5:57 PM PDT

I'm pleased to announce the availability of the Proposed Final Draft
revisions of the next release of the JavaServerTM Faces and
Pages specifications. The Faces spec may be downloaded from < href="">>
and the Pages spec may be downloaded from < href="">>
We really want feedback! Please use our href="">Forum
to share your thoughts on the specs
. Or you may send feedback to
the comments alias for title="[PUBLIC REVIEW FEEDBACK]">Faces or href="" title="[PUBLIC REVIEW
FEEDBACK]"> respectively) .

In this entry, I link to a comprehensive high level outline of the
changes to the spec since the 1.1 release of the Faces spec. I've
decided include changes present in the href="">December
Early Draft Release, the href="">April Public
Review Release and the current Proposed Final Draft release for
completeness. As such, this entry repeats some information from my href="">
blog entry on the April Public Review Release. If you're looking
for what's new since that the Public Review release only, please consult
issue tracker query.

Keep in mind this is a high level outline, for details, I
encourage you to read the relevant sections of the spec itself.

Before we get to the outline, here is a brief summary of the main

  • Unified EL

    The expression language used in Faces, which
    was inspired by the expression language used in
    JSTL and JSP, has been generalized and extracted
    into its own top level javax.el
    package. The EL is agnostic of the technology
    hosting it, such as JSP or Faces, and is intended
    to be generally useful in the same way one can use
    OGNL in a variety of applications. Faces now has
    deprecated its internal EL in favor of using the
    Unified EL.

  • New Tree Creation and Content Interweaving
    Model for Faces applications that use JSP

    While it is perfectly acceptable to use Faces
    without using JSP, many people find their
    productivity increases when using these two
    technologies together. Unfortunately, as amply
    documented by href="">Hans
    Bergsten in his article at, there
    were some integration cases that didn't work as
    expected. By changing the specification of the
    implementation of the Faces ViewHandler for JSP,
    as well as changing the JSP custom tag base class
    used by all Faces component tags, these problems
    have all been resolved.

  • Integration with JSTL

    Another long standing problem was in using JSTL's
    <c:forEach> tag to contain Faces input
    components. Because JSP has no notion of a postback, it was
    not possible to apply the values correctly to the nested input
    components on postback. By introducing some new concepts into
    the EL, it is now possible to fully use
    <c:forEach> with any kind of Faces
    component. This will require a new release of JSTL, which
    will also be present in J2EE 5, along with Faces and JSP.

  • Back Button issues and Multi Frame or Multi Window
    Faces Apps

    Due to a deficiency in the State Management API using Faces
    in Multi Frame or Multi Window applications presented some
    problems. The browser back button also could cause
    application state to become confused. These problems have now
    been fixed.

  • Associating a message with a particular component in
    the page.

    Previous revisions of the spec didn't allow for
    dynamically including the label of a component in an error
    message for that component. New spec features now allow for
    this to happen.

    It is now possible to override the conversion or
    validation message that is displayed to the user on a
    per-instance basis. For example:

    <h:inputText value="#{bean.value}"
      <f:validateLongRange maximum="1" minimum="10"/>

  • AJAX support

    As you should all know by know, AJAX is mainly a
    component thing, but there are some things the basic JSF
    framework can do to make things a little easier for those
    writing AJAXian JSF components. Even without these features
    (ie, in JSF 1.1), href="">it's
    very easy to write AJAX components for JSF and easier
    still to use them.

    Specify that the FacesServlet should look
    for an init-param called
    javax.faces.LIFECYCLE_ID to identify the Lifecycle to be
    used for processing this request. This approach allows you
    to map different instances of the FacesServlet
    with different lifecycles. For example, one mapping for
    standard JSF requests and another for AJAX JSF requests.

    Specify the name of the state saving parameter so that
    AJAX scripts can manually post back the state to the server
    using XMLHttpRequest, therefore enabling the AJAX processing
    code to have access to the full view. This approach was
    used in the href="">Progress
    Bar JSF component. The name of the parameter is

  • Expose an application wide ResourceBundle to the EL.

    We have added a new element to
    the faces-config that allows you to list zero or more
    resource bundles that should be exposed to the EL using the
    new ELResolver chain. Doing this allows performance
    optimizations that prevent the need to create a
    ResourceBundle for every request.

  • API classes use generics

    In response to strong Expert Group demand, we have
    applied Java SE 5.0 Generics to the JSF api. Therefore, the
    minimum JDK requirement for JSF 1.2 is Java SE 5.0. I'm
    told that it's possible to retroweave a binary to make it
    run under 1.4, but of course that configuration is not
    supported or recommended by Sun.

All of these features and more are currently available in the JSF
implementation found in Sun's Open Source Appserver, href="">glassfish.

Now, the outline of changes is available href="">here.

Technorati Tags:

Related Topics >>