Contenedor web

En esta sección, se describen problemas conocidos relacionados con el contenedor web, junto con las soluciones pertinentes.

No se proporciona compatibilidad con Apache e IIS para el complemento de equilibrador de carga.

Sun Java ES 5 Application Server no es compatible con Apache e IIS (contenedor web que no sea de Sun) para el complemento de equilibrador de carga. Sun Java ES instala Sun Java System Web Server para la configuración del complemento de equilibrador de carga.

La implementación de la aplicación mediante --precompilejsp=true puede bloquear los archivos JAR. (Id. 5004315)

En la plataforma Windows, si solicita una precompilación de JSP cuando implemente una aplicación en Windows, los siguientes intentos para anular la implementación o para volver a implementarla (o alguna aplicación con el mismo Id. de módulo) no funcionarán tal y como se esperaba. La precompilación de JSP abre archivos JAR en la aplicación, pero luego no los cierra y Windows impide que se anule la implementación porque no se pueden eliminar los archivos e impide que se puedan volver a implementar, puesto que no se pueden sobrescribir.

Tenga en cuenta que la anulación de la implementación es correcta hasta un punto en el que la aplicación se elimina lógicamente de Application Server. Tenga en cuenta también que la utilidad asadmin no muestra ningún mensaje de error, a pesar de que los archivos jar bloqueados y el directorio de la aplicación siguen estando en el servidor. El archivo de registro del servidor contiene mensajes en los que se indica que no se han podido eliminar los archivos ni el directorio de la aplicación.

Los intentos de volver a implementar la aplicación después de que ésta se haya anulado fallan porque el servidor trata de eliminar los archivos existentes y el directorio, pero estos intentos fallan. Esto puede suceder si intenta implementar una aplicación que utilice el mismo Id. de módulo que la aplicación que se implementó originalmente porque el servidor utiliza dicho Id. de módulo cuando elige el nombre del directorio para conservar los archivos de la aplicación.

Si intenta reimplementar la aplicación sin anular su implementación primero, se producirán fallos por las mismas razones.

Diagnóstico

Si intenta volver a implementar la aplicación o implementarla después de haberla eliminado, la utilidad asadmin devuelve un error parecido al siguiente:

An exception occurred while running the command. The exception 
message is: CLI171 Command deploy failed : Deploying application in 
domain failed; Cannot deploy. Module directory is locked and can't 
be deleted.

Solución

No se producirá este problema si especifica --precompilejsps=false (la configuración predeterminada) al implementar una aplicación. Tenga en cuenta que el primer uso que haga de la aplicación desencadenará la compilación JSP, por lo que el tiempo de respuesta para la primera solicitud será superior al de las solicitudes posteriores.

Debe saber también que si realiza una compilación previa, deberá detener y reiniciar el servidor antes de anular la implementación de la aplicación o de volver a implementarla. Al cerrar, se liberan los archivos JAR bloqueados por lo que la anulación de la implementación o el proceso para volver a implementar se realizarán correctamente.

No se puede implementar WAR con un archivo web.xml basado en Servlet 2.4 que contenga un elemento <load-on-startup> vacío. (Id. 6172006)

El elemento opcional "load-on-startup servlet" del archivo web.xml indica que el servlet asociado se debe cargar e iniciar cuando se inicie la aplicación web de la que forma parte.

El contenido opcional de este elemento es un entero que indica el orden en el que se debe cargar e iniciar el servlet con respecto a los demás servlets de la aplicación web. Si el elemento <load-on-startup> está vacío, indica que el orden no es relevante, siempre y cuando el servlet se cargue e inicie durante el inicio de la aplicación web que lo contiene.

El esquema de Servlet 2.4 de web.xml ya no admite un elemento <load-on-startup> vacío. Esto implica que debe especificarse un entero al utilizar un archivo web.xml basado en Servlet 2.4. Si se especifica un elemento <load-on-startup> vacío, como en <load-on-startup/>, el archivo web.xml no podrá realizar la validación en el esquema de Servlet 2.4 para web.xml, por lo que fallará la implementación de la aplicación web.

Problema de compatibilidad con versiones anteriores. En el caso de web.xml basado en Servlet 2.3, sí se puede dejar vacío <load-on-startup>.

Solución

Especifique <load-on-startup>0</load-on-startup> al utilizar un archivo web.xml basado en Servlet 2.4 para indicar que el orden de carga del servlet es irrelevante.

No se puede compilar la página JSP en servidores con restricciones de recursos. (Id. 6184122)

Se puede acceder a la página JSP, pero se producen fallos al compilar y el registro del servidor contiene el mensaje de error "Unable to execute command", es decir, que no se puede ejecutar el comando con este seguimiento de pila:

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)

Solución

Defina el conmutador de compilación "fork" de JSP en "false".

Puede activar esta configuración de una de las dos formas siguientes:

• Globalmente, al configurar el parámetro fork init de JspServlet en ${S1AS_HOME}/domains/domain1/config/default-web.xml en 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>

• En cada aplicación web, configurando la propiedad de configuración JSP fork de sun-web.xml en false:

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

Las dos configuraciones impedirán que Ant genere un nuevo proceso para la compilación javac.

Application Server no admite el complemento auth-passthrough de Web Server 6.1. (Id. 6188932)

Sun Java System Application Server Enterprise Edition 8.2 agrega compatibilidad para la función proporcionada por el complemento auth-passthrough que está disponible con Sun Java System Application Server Enterprise Edition 7.1. Sin embargo, en Application Server Enterprise Edition 8.2, la función del complemento auth-passthrough está configurada de forma diferente.

La función del complemento auth-passthrough en Application Server Enterprise Edition 7.1 ha resultado útil en situaciones de implementación de dos capas, con las siguientes restricciones:

• La instancia de Application Server está protegida por un segundo servidor de seguridad detrás del servidor de seguridad corporativo.

• No se permiten conexiones de clientes directamente a la instancia de Application Server:

En arquitecturas de red de este tipo, un cliente se conecta a un servidor web de principal (front-end) que se haya configurado con la función del complemento service-passthrough y reenvía solicitudes HTTP a la instancia de Application Server que actúa de proxy para que las procese. La instancia de Application Server sólo puede recibir solicitudes desde el proxy del servidor web, pero nunca directamente de los hosts clientes. En consecuencia, ninguna aplicación implementada en la instancia de Application Server que actúa de proxy que solicite información del cliente (como pueda ser la dirección IP del cliente) recibirá la IP de host del proxy, puesto que éste es el host que origina la solicitud remitida.

En Application Server Enterprise Edition 7.1, la función del complemento auth-passthrough se puede configurar en la instancia de Application Server que actúa como proxy para hacer que la información de los clientes remotos esté disponible directamente para todas las aplicaciones implementadas; de esta forma, el funcionamiento es como si la instancia de Application Server que actúa de proxy hubiera recibido la solicitud directamente en lugar de a través del servidor web intermediario que ejecuta el complemento service-passthrough.

En Application Server Enterprise Edition 8.2, la función auth-passthrough puede habilitarse configurando la propiedad authPassthroughEnabled del elemento <http-service> de domain.xml como TRUE (verdadero), de la siguiente forma:

<property name="authPassthroughEnabled" value="true"/>

Las mismas consideraciones de seguridad de la función del complemento auth-passthrough de Application Server Enterprise Edition 7.1 se aplican también a la propiedad authPassthroughEnabled de Application Server Enterprise Edition 8.2, ya que authPassthroughEnabled permite la sobrescritura de información que se puede utilizar con fines de autenticación (como la dirección IP desde la que se originó la solicitud o el certificado de cliente SSL). Por lo tanto, sólo a clientes o servidores de confianza debe permitírseles la conexión a una instancia Application Server Enterprise Edition 8.2 con authPassthroughEnabled establecido en TRUE (verdadero). Como medida de precaución, se recomienda que sólo los servidores que estén detrás de un servidor de seguridad corporativo se configuren con authPassthroughEnabled establecido en TRUE (verdadero). Un servidor que esté accesible a través de Internet nunca debe configurarse con authPassthroughEnabled definido en TRUE (verdadero).

Tenga en cuenta que en una situación en la que el servidor web proxy se haya configurado con el complemento service-passthrough y reenvíe solicitudes a una instancia de Application Server 8.1 Update 2 con authPassthroughEnabled establecido como TRUE (verdadero), la autenticación SSL de cliente puede estar habilitada en el servidor Web proxy y deshabilitada en la instancia Application Server 8.1 Update 2 que actúa de proxy. En este caso, la instancia de Application Server 8.1 Update 2 seguirá considerando la solicitud como si estuviera autenticada a través de SSL y proporcionará el certificado SSL de cliente a cualquier aplicación implementada que lo solicite.

El módulo de escucha HTTP creado con --enabled=false no deshabilita el módulo de escucha. (Id. 6190900)

Al crear un httplistener con el indicador --enabled=false, el módulo de escucha no llega a deshabilitarse. El indicador --enabled no tiene efecto alguno cuando se utiliza al mismo tiempo que se crea el módulo de escucha.

Solución

Cree el módulo de escucha con un estado habilitado; deshabilítelo manualmente más tarde.