Web Container

This section describes known web container issues and associated solutions.

Unable to deploy WAR with Servlet 2.4-based web.xml that contains an empty <load-on-startup/> element. (ID 6172006)

The optional load-on-startup Servlet element in a web.xml indicates that the associated Servlet is to be loaded and initialized as part of the startup of the Web application that declares it.

This limitation applies to Servlet 2.4-based web.xml only; it is possible to specify an empty load-on-startup element using a Servlet 2.5-based web.xml.

The optional content of this element is an integer indicating the order in which the Servlet is to be loaded and initialized with respect to the Web application's other Servlets. An empty <load-on-startup/> indicates that the order is irrelevant, as long as the Servlet is loaded and initialized during the startup of its containing web application.

The Servlet 2.4 schema for web.xml no longer supports an empty <load-on-startup/>, meaning that an integer must be specified when using a Servlet 2.4 based web.xml. If specifying an empty <load-on-startup/>, as in <load-on-startup/>, the web.xml will fail validation against the Servlet 2.4 schema for web.xml, causing deployment of the Web application to fail.

Backwards compatibility issue: Specifying an empty <load-on-startup/> still works with Servlet 2.3 based web.xml.

Solution

Specify <load-on-startup/>0</load-on-startup/> when using a Servlet 2.4 based web.xml to indicate that Servlet load order does not matter.

Unable to compile JSP page on resource constrained servers. (ID 6184122)

The JSP page is accessed but fails to compile, and the server log contains the error message “Unable to execute command” with the following stack trace:

at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec
(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.launch
(Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute
(Execute.java:427) at org.apache.tools.ant.taskdefs.compilers.
DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.
java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal.
execute(JavacExternal.java:81) at org.apache.tools.ant.taskdefs.Javac.
compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute
(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass
(Compiler.java:396)

Solution

Set the JSP compilation switch fork to false.

This can be done either of two ways:

• Globally, by setting the fork init parameter of the JspServlet in ${S1AS_HOME}/domains/domain1/config/default-web.xml to false:

  <servlet\> <servlet-name\>jsp</servlet-name\> <servlet-class\>org.apache.
  jasper.servlet.JspServlet</servlet-class\> .... <init-param\> <param-name\>
  fork</param-name\> <param-value\>false</param-value\> </init-param\> .... 
  </servlet\>

• On a per-web application basis, by setting the fork JSP configuration property in sun-web.xml to false:

  <sun-web-app\> <jsp-config\> <property name="fork" value="false" /\> 
  </jsp-config\> </sun-web-app\>

Either setting will prevent ant from spawning a new process for javac compilation.

ParserUtils picks up parser from web app (ID 6412405)

When accessing a JSP, the following exception may be logged under certain circumstances:

java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.
setDocumentURI(Ljava/lang/String;)V

Solution

Add the following system property to your domain.xml file:

<jvm-options>-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces. \
internal.jaxp.DocumentBuilderFactoryImpl</jvm-options>

Alternatively, remove the JAR file containing the org.apache.xerces package form your Web application's WEB-INF/lib.

TLDs in EAR-bundled JARs not found. (Glassfish Issue 590)

JAR-packed JSP tag libraries bundled in EAR files cannot be referenced by the JSP pages of a WAR file that is part of the EAR, even if the META-INF/MANIFEST.MF resources of that WAR file lists the tag library JAR file(s) in its Class-Path manifest attribute.

When accessing a JSP page that imports a tag library packaged in one the EAR file's JAR files, an error message similar to the following will appear in the server log and the JSP page will fail to compile:

The absolute uri: <taglib_uri> cannot be resolved in either web.xml or 
the jar files deployed with this application

Solution

Bundle any JSP tag library JAR files in the WEB-INF/lib directory of any WAR file whose JSP pages import those tag libraries.

More information about this bug can be found on the Glassfish site at https://glassfish.dev.java.net/issues/show_bug.cgi?id=590.