JavaServer ^TM Faces Release Notes
Known Issues

Known issues with the 1.2_09 release.

• The default renderer for h:dataTable doesn't produce accessible markup - specifically no scope attribute is rendered on table rows (see issue 341).

• When upgrading from 1.2 to 1.2_01, 1.2_02, or 1.2_03, 1.2_04, or 1.2_05 on Tomcat 5.x with Facelets, the user may receive a ClassNotFoundException for com.sun.faces.config.GlassFishConfigureListenener. In order to resolve this, delete the tld cache references under TOMCAT_HOME/work and restart the server.

• When upgrading to 1.2_05 or later while running on a Servlet 2.4 container the following error may be encountered:

                com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED!Unable to parse document 'file:/C:/develop/Java/Tomcat
  -5.5.25/work/Catalina/localhost/server/loader/com/sun/faces/jsf-ri-runtime.xml': This parser does not support specificat
  ion "null" version "null"
            

  This error indicates the version of JAXP being used with the container is not compliant with JAXP 1.3 or later. Refer to the container's documentation for details on how to upgrade JAXP.

• In the JSF-RI 1.1 series it was possible to use jsp:include with nested jsp:params. This is no longer possible with JSF-RI 1.2. This is not a true backwards compatibility issue. The fact that it worked in 1.1 was due to a side-effect of a workaround for a Tomcat 4 bug. Had this workaround be removed, usage of jsp:param would have failed. We've evaluated potential ways to enable this functionality in 1.2, but have decided that this issue will not be resolved.

• Exceptions thrown by a method marked with @PostConstruct are swallowed so that the root cause isn't logged. A possible workaround is to surround the body of the @PostConstruct method with try/catch, log the exception and rethrow.

• Groovy support fails in recent builds of GlassFish V3 (which includes 1.2_09) when installing groovy-1.5.5-all.jar (or later) as an OSGi bundle in the v3 modules directory (currently, this is the only way to make Groovy available to JSF).

  When attempting to resolve a Groovy resource, the following error may occur:

                  BUG! exception in phase 'semantic analysis' in source unit ...
              

  The problem is due to groovy-1.5.5-all.jar not exporting all of the packages necessary to resolve the classes needed to compile a groovy source file at runtime.

  We've logged GROOVY-3001 to track this and have offered a suggested fix that we've tested locally. This having been said, it's quite easy to build Groovy from source. The fix is quite simple as it's a simple build change. The following diffs modify the Export-Package section of the top-level build.xml for Groovy 1.5.5:

                  --- build.xml	2008-04-14 17:28:06.000000000 -0700
                  +++ build.xml	2008-08-14 09:09:57.000000000 -0700
                  @@ -484,7 +484,13 @@
                   org.codehaus.groovy.tools.xml,
                   org.codehaus.groovy.vmplugin,
                   org.codehaus.groovy.vmplugin.v4,
                  -org.codehaus.groovy.vmplugin.v5" />
                  +org.codehaus.groovy.vmplugin.v5,
                  +groovyjarjarantlr,
                  +groovyjarjarantlr.actions,
                  +groovyjarjarantlr.actions.java,
                  +groovyjarjarantlr.collections,
                  +groovyjarjarantlr.collections.impl,
                  +groovyjarjarantlr.preprocessor" />
                                   <attribute name="Eclipse-BuddyPolicy" value="dependent"/>
                                   <attribute name="Eclipse-LazyStart" value="true"/>
                               </manifest>
  
              

  All that's needed at this point is copying the new groovy-1.5.5-all.jar to V3's modules directory and restarting.