Revised: 20040204
The purpose of this release is to provide a reference implementation of the JavaServer Faces framework.
This FCS release of JavaServer Faces technology provides a final version of the JSF technology which was developed under the Java Community Process(SM) ("JCP(SM)") as JSR127.
Software | Version
|
---|---|
Java Development Kit | version 1.3.1 or later |
Java Web Services Developer Pack | version 1.3 |
Microsoft Internet Explorer or Netscape Navigator | version 6 (IE)
version 7 (Netscape) |
Please see the README.
This implementation is 100% compatible with the 1.0 implementation, but many bugs have been fixed. If your application dependend on one of these bugs, it will need to be changed. Please see the What's New section in the README.
The Map returned by the UIComponent.getAttributes() method implements get() so that if you ask for a key that is implemented as a property, you get the property value. However, if you call iterator() on the Map, you will get an Iterator that iterates over the "real" attributes only, not the properties.
the value of
javax.faces.component.NamingContainer.SEPARATOR_CHAR
is ':
'. This means that the client id for
components will be something like
"form:checkbox1
". The use of the
':
' character in the id causes problems for CSS
stylesheets that try to apply style to components using their
id. The workaround is to use the CSS "class
"
concept to apply style to a component.
When saving state on the server, there is no way for the server to know that a view has expired. Thus, if the JSP page changes between requests, it's possible there will be inconsistencies between the restored tree and the JSP page. Therefore, if you change the JSP page, you need to re-start the browser so that the session is lost.
In related news, the number of views saved in the session when the
application is configured to save state in the server is configurable by
the RI init context parameter
"com.sun.faces.NUMBER_OF_VIEWS_IN_SESSION
" without quotes.
This is a non-standard feature, so don't count on it.
Don't use the '.' character in
ResourceBundle
keys for use in Faces. This
character is a reserved character in the JSF EL.
When deploying on a non-JWSDP container, you must include all the dependent jars in your webapp's WEB-INF/lib directory. It's possible it may work without doing this, but this is not a supported configuration.
If you're using a SunOne Application Server 7.x, Tomcat 4 series container, or any container that strictly conforms to JSP 1.2, Servlet 2.3, you must use JSTL 1.0 instead of JSTL 1.1.
There is a known issue in S1AS 7.x, Tomcat 4.x, and Tomcat 5.x where security constraints are applied to welcome files. The bug number for this S1AS 7.x issue is #5004853.
This bug is problematic for the jsf-cardemo
application since the security constraint is applied to the
index.jsp
welcome file. Since this container
applies the security constraint to the welcome file, the
container displays an error page when an attempt to access
the application is made. On older versions of S1AS 7.x
that error code is incorrectly reported as 500. This has since
been fixed to be the correct number 403.
To get around this problem either:
http://<SERVER>:<PORT>/jsf-cardemo/chooseLocale.faces
web.xml
welcome file to exclude the
index.jsp
page.The Java Systems Application Server 8.0 and JWSDP 1.3 do not have this problem and properly exclude welcome files from the security constraints.
The Non-JSP demo does not deploy under tomcat 4.1.29.
Some versions of some web containers, such as Resin and Oracle App Server,
don't follow the Servlet 2.3 Spec rule of calling
ServletContextListeners listeners defined in tld files in the
META-INF directory of a jar. Running a faces webapp in such a
container requires you to manually declare the
ServletContextListener. The listener-class
you
need to specify is
com.sun.faces.config.ConfigureListener
disabledClass
property specified on
SelectOneRadio
tag is not applied to the individual
selectItem
(options).
If you're using component bindings pointing to beans stored in session scope with values initialized from the JSP page, you may run into some difficulties in the "edit-compile-debug" cycle.
Consider this JSP fragment:
<h:commandButton binding="#{backingBean.button1}" value="press me" />
Let's say that "backingBean" is stored in session scope. The first time the browser views this page, backingBean gets instantiated, and initialized with the value "press me". Now, let's say the web-app is being authored in place, on the web container. In other words, any changes made to the JSP are seen "live" on the server. If you change the JSP to alter the value of the button to be different, say like this:
<h:commandButton binding="#{backingBean.button1}" value="click me" />
and save the page, then re-load the page in the browser, you'll see that the button still shows up with the old label, "press me". This is because the spec is designed to only initialize the backing bean with a value the first time the page is loaded, and the bean is still sitting in the session with the old value. There are several workarounds to this problem.
use "request" or "none" scope for your backing bean
use java code to push the value into the bean, rather than JSP
ask the user to re-start their browser after modifying the JSP page.
find a way to invalidate the session when the JSP page has changed.
Copyright © 2004 Sun Microsystems, Inc., 4150 Network Circle, Santa
Clara, California 95054, U.S.A. All rights reserved.
Sun Microsystems, Inc. has intellectual property rights relating to
technology embodied in this product. In particular, and without
limitation, these intellectual property rights may include one or more
of the U.S. patents listed at http://www.sun.com/patents and one or
more
additional patents or pending patent applications in the U.S. and other
countries.
This product is distributed under licenses restricting its use, copying
distribution, and decompilation. No part of this product may be
reproduced in any form by any means without prior written authorization
of Sun and its licensors, if any.
Third-party software, including font technology, is copyrighted and
licensed from Sun suppliers.
Sun, Sun Microsystems, the Sun logo, the Java Coffee Cup logo,
JavaServer, and Java are trademarks or registered trademarks of Sun
Microsystems, Inc. in the U.S. and other countries.
Federal Acquisitions: Commercial Software - Government Users Subject
to
Standard License Terms and Conditions.
Copyright © 2004 Sun Microsystems, Inc., 4150 Network Circle,
Santa Clara, California 95054, Etats-Unis. Tous droits réservés.
Sun Microsystems, Inc. a les droits de propriété intellectuels
relatants
à la technologie incorporée dans ce produit. En particulier,
et sans la
limitation, ces droits de propriété intellectuels peuvent
inclure un ou
plus des brevets américains énumérés à
http://www.sun.com/patents et un
ou les brevets plus supplémentaires ou les applications de brevet
en
attente dans les Etats - Unis et les autres pays.
Ce produit ou document est protégé par un copyright et
distribué avec
des licences qui en restreignent l'utilisation, la copie, la
distribution, et la décompilation. Aucune partie de ce produit
ou
document ne peut être reproduite sous aucune forme, par quelque
moyen
que ce soit, sans l'autorisation préalable et écrite
de Sun et de ses
bailleurs de licence, s'il y ena.
Le logiciel détenu par des tiers, et qui comprend la technologie
relative aux polices de caractères, est protégé
par un copyright et
licencié par des fournisseurs de Sun.
Sun, Sun Microsystems, le logo Sun, le logo Java Coffee Cup, JavaServer,
et Java sont des marques de fabrique ou des marques déposées
de Sun
Microsystems, Inc. aux Etats-Unis et dans d'autres pays.