Instalación de Struts
Prerequisitos de Software
Para construir una distribución fuente, o instalar una distribución binaria de Struts, necesitaremos adquirir e instalar otros varios paquetes de software:
- Java Development Kit - Debemos descargar e instalar una implementación del JDK de Java (versión 1.2 o superior) para nuestra plataforma de sistema operativo. Un punto de partida para localizar las distribuciones del JDK es http://java.sun.com/j2se.
- Servlet Container - Debemos descargar e instarlar un contenedor de sevlets que sea compatible con la especificación del API Servlet, versión 2.2 o posterior, y la especificación JavaServer Pages (JSP), versión 1.1 o posterior. Una elección popular es Tomcat de Apache (versión 3.1 o posterior, recomendamos la versiones 3.2 o posteriores).
- Ant Build System - Si estámos construyendo Struts desde la distribución fuente, debemos descargar e instalar una versión 1.3 o posterior de Ant. Este paquete también es altamente recomendado para usarlo en el desarrollo de nuestras aplicaciones Web basadas en Struts.
- Si estámos usando la versión 1.3 de Ant, necesitaremos descargar el fichero "optional.jar" que contiene la implementación del comando <style> de Ant.
- Nos aseguramos de que los scripts "ant" y "ant.bat" son ejecutables, añadiendo el directorio $ANT_HOME/bin a nuestra variable de entorno PATH.
- Servlet API Classes - Para poder compilar el propio Struts, o las aplicaciones que usan Struts, necesitaremos un fichero servlet.jar que contenga las clases de los APIs Servelt y JSP. La mayoría de los contenedores de servlets incluyen este fichero JAR. Si no es así, podemos obtener la distribución de estas clases desde aquí.
- JDBC 2.0 Optional Package Classes - Struts soporta una implementación opcional de javax.sql.DataSource, por eso requiere que se compile el API de clases. Se pueden descargar desde http://java.sun.com/products/jdbc/download.html.
- XML Parser - Struts requiere la presencia de un analizador XML que sea compatible con la especificación del API Java para XML Parsing (JAXP), 1.0 o posterior. Podemos descargar e instalar la implementación de referencia del API JAXP, que es requerido para construir la distribución fuente de Struts. En aplicaciones web basadas en Struts, podríamos reemplazar las clases de la implementación de referencia con cualquier otro analizador compatible con JAXP, como Xerces.
- Xalan XSLT Processor - Si estamos construyendo Struts desde la distribución fuente, debemos descargar e instalar la versión 1.2 (se han reportado problemas con la versión 2.0 de Xalan) del procesador XSLT Xalan (que también incluye el analizador XML Xerces), o usar la versión de Xalan incluida en la versión 1.1 de JAXP. Este procesador es usado para convertir la documetnación de Struts de su formato interno basado en XML al formato HTML que se presenta en la documentación de la aplicación Struts.
Construir Struts desde el Código Fuente
Primero descargamos una distribución fuente de Struts siguiendo las instrucciones de aquí. Después debemos asegurarnos de haber descargado e instalado todos los paquetes de software de la sección prerequisitos
Para construir Struts, necesitaremos personalziar el proceso de construcción con los detalles de nuestro entorno de desarrollo según lo siguiente:
- La distribución fuente de Struts usa un fichero llamado build.properties ( en el directorio de más alto nivel de la distribución) para identificar la localización de componentes externos de los que depende Struts.
- No hay un fichero build.properties incluido con la distribución fuente. Sin embargo, hay un fichero de ejemplo llamado build.properties.example que podemos copiar como build.properties y luego personalizarlo.
- Las propiedades que debemos configurar en build.properties son:
- catalina.home - Pathname al directorio de nuestra disribución binaria de Tomcat 4.0 (requerido sólo si deseamos usar la fuente deploy.catalina).
- servletapi.home - Pathname al directorio de nuestra distribución binaria de las clases del API Servlet.
- tomcat.home - Pathname al directorio de la distribución binaria de Tomcat 3.2 (sólo si deseamos utilizar la fuente deploy.tomcat).
- xerces.home - Pathname al directorio de la distribución binaria del analizador Xerces, versión 1.2 o 1.3 (requerido sólo si deseamos usar la fuente deploy.catalina).
- Si somos un desarrollador Struts con acceso de escritura al repositorio CVS, nos aseguramos de no marcarlo en la copia del fichero build.properties, ya que será diferente para cada desarrollador individual.
Para construir una versión "distribución" de Struts, primero cambiamos nuestro directorio actual al directorio en el que hemos desempaquetado la distribución fuente de Struts, y (si es necesario) creamos o personalizadmos el fichero build.properties como se describre arriba. Luego tecleamos:
ant dist
Este comando creará una distribución binaria de Struts, en un directorio llamado dist (en relación a desde donde lo compilamos). Este directorio contiene una réplica exacta de los ficheros incluidos en la distribución binaria de Struts.
NOTA IMPORTANTE: El fichero struts.jar debe estar en nuestro classpath cuando compilemos Struts. El build.xml hace esto automáticamente. Si usamos nuestra máquina de desarrollo para probar localmente la aplicación Struts, debemos asegurarnos de que stuts.jar no está en nuestro classpath cuado se ejecute el contenedor.
Instalar un Distribución Binaria de Struts
Primero descargamos una distribución fuente de Struts siguiendo las instrucciones de aquí. Después debemos asegurarnos de haber descargado e instalado todos los paquetes de software de la sección prerequisitos
Desempaquetamos la distribución binaria de Struts dentro de un directorio conveniente. (Si construimos Struts desde la distribución fuente, el resultado ya estára en una distribución binaria desempaquetada). La distribución consta de los siguientes contenidos:
- lib/struts.jar - Este fichero JAR contiene las clases Java incluidas en Struts. Debería copiarse en el directorio WEB-INF/lib de nuestra aplicación Web.
|
CUIDADO: - Si vamos a hospedar múltiples apliaciones basadas en Struts en el mismo contenedor de servlets, podríamos vernos tentados a poner el fichero struts.jar en el repositorio compartido sportado por nuestro contenedor. Debemos estar avisados de que hacer esto causará que nos encontremos problemas de ClassNotFoundException a menos que todas las clases de las aplicaciones estén almacenadas en el mismo repositorio compartido.
|
- lib/struts*.tld - Estos son ficheros "descriptores de librerías de etiquetas" que describen las etiquetas personalizadas en las distintas librerías de Struts. Deberían copiarse en el directorio WEB-INF de nuestra aplicación web.
- webapps/struts-blank.war - Este es un simple fichero "web application archive" que contiene un punto de entrada básico para construir nuestras aplicaciones basadas en Struts.
- webapps/struts-documentation.war - Es un fichero "web application archive" que contiene toda la documentación sobre Struts encontrada en la web site de Struts (incluyendo estás páginas). Podemos instalar esta aplicación web sobre cualquier contenedor Servlet compatible con el API Servlet 2.2 o posterior.
- webapps/struts-example.war - Este es un ejemplo de aplicación web que usa un gran porcentaje de las características de Struts. Podemos instalar esta aplicación web en cualquier contenedor servlet compatible con las especificaciones Servlet 2.2 (o posterior) y JSP 1.1 (o posteriores). Si no tenemos disponible ningún analizador XML para las aplicaciones Web en nuestro contenedor, necesitaremos añadir uno al directorio WEB-INF/lib de esta aplicación web.
- webapps/struts-exercise-taglib.war - una aplicación web que contiene páginas de prueba para varias etiquetas personalizadas soportadas por Struts. Esta pensado para su uso por desarrolladores que quieren ampliar las librerías personalizadas de Struts, pero podría ser útil como un simple ejemplo del uso de varias etiquetas Struts.
- webapps/struts-template.war - Esta aplicación web presenta y desmuestra las etiquetas de plantillas de Struts.
- webapps/struts-upload.war - Esta aplicación web es un rápido ejemplo para subir ficheros usando el marco de trabajo Struts.
Para usar Struts en nuestra aplicación, necesitamos seguir estos pasos:
- Copiar el fichero lib/struts.jar desde la disribución de Struts al directorio WEB-INF/lib de nuestra aplicación web.
- Copiar todos los ficheros que correspondan con lib/struts*.tld desde la distribución de Struts al directorio WEB-INF de nuestra aplicación web.
- Modificar el fichero WEB-INF/web.xml de nuestra aplicación web para incluir un elemento <servlet> que defina el servlet controlador, y un elemento <servlet-mapping> que establezca que URIs solicitadas serán mapeadas a este servlet, Usamos el fichero WEB-INF/web.xml del ejemplo de aplicación Struts para ver la sintaxis requerida.
- Modificar el fichero WEB-INF/web.xml de nuestra aplicación para incluir las siguientes declaraciones de librerías de etiquetas:
<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-html.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-logic.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-template.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-template.tld</taglib-location>
</taglib>
- Crear un fichero WEB-INF/struts-config.xml que defina los mapeos de action y otras características de nuestra aplicación. Podemos usar el fichero struts-config.xml del ejemplo de aplicación Struts para ver la sintaxis requerida.
- Al principio de cada página JSP que use las etiquetas personalizadas de Struts, añadimos las líneas declarando las librerías Struts a utilizar en esa página particular, como esta:
<@ taglib uri="/WEB-INF/struts-bean.tld" prefix="struts-bean" %>
<@ taglib uri="/WEB-INF/struts-html.tld" prefix="struts-html" %>
<@ taglib uri="/WEB-INF/struts-logic.tld" prefix="struts-logic" %>
<@ taglib uri="/WEB-INF/struts-template.tld" prefix="struts-template" %>
- Cuando compilemos las clases Java que comprenden nuestra aplicación, debemos asegurarnos de incluir el fichero struts.jar (copiado anteriormente) en el CLASSPATH que es enviado al compilador.
Instalar Struts con nuestro Contenedor de Servlets
|
CUIDADO: - NO debemos añadir el fichero struts.jar al classpath de nuestro contenedor de servlets en un intento de evitar situarlo en el directorio /WEB-INF/lib individual de cada aplicación. Hacer esto causará que nos encontremos problemas de ClassNotFoundException.
|
Para la mayoría de los contenedores, sólo necesitaremos:
- Copiar los ficheros WAR en nuestro directorio /webapp Struts al directorio webapps de nuestro contenedor.
- En algunos casos, necesitaremos reiniciar nuestro contenedor si se está ejecutando.
A contiuación podremos ver el estado de varios contenedores.
Bluestone Universal Business Server 7.2
- Necesitamos UBS versión 7.2 para ejecutar ficheros de aplicación war. Aquí puedes encontrar la versión de evaluación de UBS 7.2.2.
Si estamos usando la versión, 7.2.1, necesitaremos descarga el patch de ficheros WAR, localizado aquí
- Después de la instalación de la correcta versión y/o patch de UBS 7.2, necesitamos modificar el fichero apserver.txt para que apunte al directorio correcto de nuestros ficheros war de aplicaciones. Busca la sección que dice algo similar a esto:
[SaServletEngine.class]
session_affinity=1
type=1
program=/SaServletEngine.class
file_path=f:\webapps
host=localhost:20000
- Usamos el directorio especificado por la variable "file_path", o lo modificamos para apuntar a nuestro directorio webapp personalizado. Copiamos los ficheros struts-documention.war y struts-example.war dentro del directorio webapp, y arrancamos UBS. Nuestras aplicaciones web son ahora accesibles desde las siguientes URLs:
http://localhost/<PLUGIN>/SaServletEngine.class/struts-example/
http://localhost/<PLUGIN>/SaServletEngine.class/struts-documentation/
- Nota: <PLUGIN> representa el pluging que hemos usado para nuestro servidor web especifico. Para Apache sobre Winodws, podría ser "cgi-bin/SaCGI.exe", para IIS sobre Windows, podría ser "scripts/SaCGI.exe" o "scripts/ISAPI.dll". Consulta la documentación de UBS para más información.
Borland Application Server 4.5
No requiere pasos adicionales.
iPlanet Application Server
Se recomienda el Service Pack 2.
Observa que el objeto de base de datos de la aplicación de ejemplo de Struts no es compatible con este contenedor.
iPlanet Web Server
Se recomienda el Service Pack 2.
Nota: Por el momento, la aplicación de ejemplo Struts todavía usa un atributo de contexto servlet no-serializable, y no se ejecutará en un entorno que los requeirea, como iPlanet Application Server.
iPlanet Web Server 4.2
Aquí están los problemas que me he encontrado cuando movía mis aplicaciones basadas en Struts desde Tomcat (que soporta WebApps y WAR) a iWS 4.1 (que NO soporta Webapps y WAR).
Webapps y WAR se soportarán en iWS 5.0, como se menciona en el iWS5.0 roadmap.
- Problemas de Classpath:
Esta bastante correcto. Como no hay noción de WEB-INF/lib y WEB-INF/classes el classpath debe seleccionarse explícitametne en $SERVER_ROOT/config/jvm12.conf.
- Paths relativos al contexto:
Todas las URLs deberían ser visibles desde el documento raíz. En mi caso sólo cree un enlace simbólico desde $DOCROOT/myapp hacia webapps/myapp.
- Mapeos de Extensión:
El fichero de configuración $SERVER_ROOT/config/rules.properties tiene un mecanismo similar a web.xml.
Yo tengo esto en mi rules.properties lo que reenvia todas las URLs que terminan en "do" al servlet cuyo nombre lógico es action.
####
@.*[.]do$=action
####
iPortal Application Server
Probado con: Windows 2000
Nota importante:
Por el momento, iPAS 1.3 no es totalmente compatible con la especificación JSP 1.1/1.2
|
Específicamente, no se han implementado la conversión automática de tipos para parémetros de etiquetas personalizadas.
Mientras tanto, las páginas JSP que hacen uso de las librerías de etiquetas Struts cuyos parámetros requieren conversión (como los booleanos) no se compilarán bajo iPAS. Esto incluye la aplicación de ejemplo se Struts. Itentar ejecutar la aplicación de ejemplo resultará en el lanzamiento de una excepción similar a esta:
/struts-example/index.jsp:
Compilation failed [IT_Builder:1000]
at com.iona.j2ee.builder.JavaBuilder.build(JavaBuilder.java:84)
at com.iona.j2ee.builder.JspBuilder.build(JspBuilder.java:51)
at com.iona.j2ee.builder.WarBuilder.build(WarBuilder.java:111)
at com.iona.j2ee.builder.EarBuilder.build(EarBuilder.java:99)
at com.iona.j2ee.builder.EarBuilder.main(EarBuilder.java:223)
at iportal.build.main(build.java:14)
ocale(boolean) in org.apache.struts.taglib.html.HtmlTag
cannot be applied to (java.lang.String)
_x0.setLocale("true");
^
1 error
Las siguientes instrucciones describen cómo instalar la aplicación de ejemplo de Struts bajo iPAS 1.3.
Las siguientes instrucciones asumen que:
- Se ha instalado iPortal Application Server 1.3.
- Tanto las librerías Struts como del Parser XML están en nuestro classpath.
Instalar la aplicación de ejemplo Struts
- Arrancamos iPAS Services pulsando sobre el ítem de menú [Start iPAS Services].
- Arrancampos el iPortal Application Server pulsando sobre el ítem de menú [iPortal Application Server].
- Arrancamos un shell de línea de comandos. Cambiamos al $INSTALLDIR\IONA y ejecutamos el fichero setenvs.bat.
- Creamos un directorio llamado jars.
Ahora ejecutamos la herramienta EARSCO. Tecleamos java iportal.earsco y en los prompts hacemos:
- Next
- Tecelamos el nombre de la aplicación struts-example y pulsamos next.
- En el paso tres pulsamos el check box e introducimos el nombre del fichero WAR struts-example. Luego pulsamos next.
- Pulsamos sobre Finish.
Ahora debemos copiar los contenidos de struts-example war dentro de la estructura de directorio EARSCO como sigue:
Bajo $INSTALLDIR\IONA\jars\struts-examples\src\struts-example.war copiamos los contenidos de los siguientes directorios: etc, lib, src y web.
Ahora estamos listos para compilar y desplegar struts-example.
Para compilar el código fuente de $INSTALLDIR\IONA\jars\struts-examples tecleamos:
java iportal.build
Luego tecleamos:
java iportal.deploy
La primera vez que despleguemos se nos pedirá que suministremos las localizaciones de los ficheros struts-example.ear y cc.xml. Una vez satisfechos ambos elementos continuamos hasta el botón finish y lo puslamos. El fichero EAR se debería desplegar satisfactoriamente.
Probamos la aplicación de ejemplo usando la siguiente URL en el navegador:
http://hostname:9000/struts-example/index.jsp
El fichero struts-documentation.war se puede instalar usando el mismo procedimiento.
Parchear la aplicación de ejemplo de Struts
Como se mencionó al principio de estas notas, la aplicación de ejemplo de Struts no funciona bajo iPAS 1.3 sin modificarla. Necesitamos hacer los siguientes cambios_
- index.jsp, logon.jsp: Cambiamos <html:html locale="true"> a <html:html locale=<%= true %>>
- registration.jsp, subscription.jsp: Cambiamos todos los ejemplares de filter="true" a filter=<%= true %>
Jetty Java HTTP Servlet Server
Jetty es un pequeño servidor HTTP puro Java y de código abierto que soporta las especificaciones Servlet 2.2 y JSP 1.1. Jetty puede descargarse desde http://www.mortbay.com/jetty.
Los ficheros WAR de Struts funcionan casi perfectametne cuando los situamos en el directorio webapps de Jetty. El único paso adicional necesario es añadir una entrada a cada fichero WAR para que el fichero de configuración del servidor Jetty pueda mapear las solicitudes de paths apropiadadas a las aplicaciones web Struts (usando "<Call name="addWebApplication">...").
Por eso por ejemplo, si hemos copiado los ficheros WAR que vienen con la distribución binaria de Struts en un subdirectorio de "%JETTY_HOME%/webapps" llamado "%JETTY_HOME%/webapps/struts" por eso que
- %JETTY_HOME%/webapps/struts/struts-documentation.war
- %JETTY_HOME%/webapps/struts/struts-example.war
- %JETTY_HOME%/webapps/struts/struts-exercise-taglib.war
- %JETTY_HOME%/webapps/struts/struts-template.war
- %JETTY_HOME%/webapps/struts/struts-upload.war
- %JETTY_HOME%/webapps/struts/struts-blank.war
y si queremos ejecutar Jetty usando el fichero de configuración demo.xml que viene con Jetty, sólo tenemos que añadirle los siguientes bloques en cualquier lugar después de que se declaren los Listeners.
<!-- Jetty config for Struts BEGIN -->
<Call name="addWebApplication">
<Arg>/struts/struts-documentation/*</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/webapps/struts/struts-documentation.war</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">false</Arg> <!-- if true,
expand war in temp dir -->
</Call>
<Call name="addWebApplication">
<Arg>/struts/struts-example/*</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/webapps/struts/struts-example.war</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">true</Arg> <!-- if true,
expand war in temp dir -->
</Call>
<Call name="addWebApplication">
<Arg>/struts/struts-exercise-taglib/*</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/webapps/struts/struts-exercise-taglib.war</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">false</Arg> <!-- if true,
expand war in temp dir -->
</Call>
<Call name="addWebApplication">
<Arg>/struts/struts-template/*</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/webapps/struts/struts-template.war</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">true</Arg> <!-- if true,
expand war in temp dir -->
</Call>
<Call name="addWebApplication">
<Arg>/struts/struts-upload/*</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/webapps/struts/struts-upload.war</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">true</Arg> <!-- if true,
expand war in temp dir -->
</Call>
<Call name="addWebApplication">
<Arg>/struts/struts-blank/*</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/webapps/struts/struts-blank.war</Arg>
<Arg><SystemProperty name="jetty.home"
default="."/>/etc/webdefault.xml</Arg>
<Arg type="boolean">true</Arg> <!-- if true,
expand war in temp dir -->
</Call>
<!-- Jetty config for Struts END -->
JRUN 3.0 SP2A, VERSION 3.02A.11614 -- Probado con Microsoft IIS 5.0, Windows 2000
Nota importante:
Por el momento, JRUN no es totalmente compatible con la especificación JSP 1.1/1.2
|
Específicamente, no se han implementado la conversión automática de tipos para parémetros de etiquetas personalizadas.
Mientras tanto, las páginas JSP que hacen uso de las librerías de etiquetas Struts cuyos parámetros requieren conversión (como los booleanos) no se compilarán bajo JRun. Esto incluye la aplicación de ejemplo se Struts. Itentar ejecutar la aplicación de ejemplo resultará en el lanzamiento de una excepción similar a esta:
/struts-example/index.jsp:
javax.servlet.ServletException: Compilation error occured:
allaire.jrun.scripting.DefaultCFE:
Errors reported by compiler:
c:/JRun/servers/default/Struts
Example/WEB-INF/jsp/jrun__index2ejspa.java:41:1:41:27:
Error: No match was found for method "setLocale(java.lang.String)".
Las siguientes instrucciones describen cómo instalar la aplicación de ejemplo de Struts bajo JRun.
Las instrucciones asumen que:
- JRun ha sido instalado e integrado con el servidor web de nuestra elección.
- $APP_SERVER_NAME es el nombre del servidor de aplicación usado para hospedar la aplicación (Cuando JRun se instaló por primera vez, creo un servidor de aplicaciones llamando JRun Default Server).
- $APP_SERVER_DIR es el directorio usado para contener las aplicaciones hospedadas por $APP_SERVER_NAME. Para el JRun Default Server, el directorio es $JRUN_HOME/servers/default donde $JRUN_HOME es el directorio donde está instalado JRun.
Instalar la aplicación de ejemplo de Struts
La aplicación struts-documentation.war puede instalarse usando el mismo procedimiento.
Instalar Aplicaciones Web Desempaquetadas
Los pasos de arriba deberían seguirse para aplicaciones desplegadas como ficheros *.war.
Para aplicaciones Web desempaquetadas, la configuración implica los siguientes pasos:
- Desde la Consola de Control de JRun, seleccionamos $APP_SERVER_NAME (en el panel izquierdo) y pulsamos sobre WAR Deployment (en el panel derecho).
- En el panel derecho, pulsamos sobre Create an Application y completamos el fomulario Web Application Information de esta forma:
- Pulsamos sobre Create para enviar el formulario.
- Una vez creada la aplicación, instalamos y configuramos los componentes Struts (struts.jar, Struts*.tld, etc.) para la aplicación Web bajo $APP_SERVER_NAME/myApplication/WEB-INF.
- Instalamos el resto de los componentes de la aplicación: ficheros .class, páginas JSP, ficheros .properties etc, según sean necesarios.
- Para configurar el mapeo de extensión de la URI solicitada (por ejemplo, *.do) al servlet action, expandimos $APP_SERVER_NAME en el panel izquierdo, en el mismo panel, expandimos la rama Web Applications y pulsamos sobre myApplication. El panel derecho mostrará las opciones de configuración para myApplication. Pulsamos sobre Servlet URL Mappings. Se mostrará una lista de mapeos existentes. Pulsamos sobre el botón Edit y creamos la siguiente entrada:
- Virtual Path/Extension: *.do
- Servlet Invoked: action.
- Pulsamos sobre el botón Update para grabar los campos.
- Reiniciamos el servidor de aplicaciones.
- Ahora la aplicación debería ser accesible desde el navegador.
El servidor de aplicaciones JRun debe reiniciarse cada vez que se hace uno de estos cambios en la aplicación Web:
- Se modifican los ficheros .class o .jar.
- Se modifican los ficheros .properties.
- Se modifican los ficheros .xml.
Parchear la aplicacion de ejemplo Struts
Como se mencionó al principio de estas notas, la aplicación de ejemplo de Struts no funciona bajo JRun sin modificarla. Necesitamos hacer los siguientes cambios:
- index.jsp, logon.jsp: Cambiamos <html:html locale="true"> a <html:html locale=<%= true %>>
- registration.jsp, subscription.jsp: Cambiamos todos los ejemplares de filter="true" a filter=<%= true %>
Orion Application Server
En los siguientes pasos, $ORION_HOME se refiere al directorio en el que hemos instalado Orion, y $STRUTS_HOME es el directorio en el que hemos desempaquetado la distribución binaria de Struts
- Modificamos el fichero $ORION_HOME/config/application.xml para definir las dos nuevas aplicaciones, añadiendo las siguientes declaraciones inmediatamente después de la directiva web-module para la aplicación Web por defecto:
<web-module id="strutsDoc"
path="$STRUTS_HOME/webapps/struts-documentation.war"/>
<web-module id="strutsExample"
path="$STRUTS_HOME/webapps/struts-example.war"/>
- Modificamos el fichero $ORION_HOME/config/default-web-site.xml (o el fichero de configuración para cualquier otra web site Orion) para incluir las siguientes declaraciones:
<web-app application="default" name="strutsDoc"
root="/struts-documentation"/>
<web-app application="default" name="strutsExample"
root="/struts-example"/>
- Después de arrancar Orion, deberíamos poder acceder a estas aplicaciones (asumiendo que no hemos cambiado el número de puerto por defecto: 80 ) en
http://localhost/struts-documentation
http://localhost/struts-example
- Las versiones de Orion hasta la 1.0.3 tiene un bug relacionado con llamadas a ServletContext.getResource() que evita que la aplicación de ejemplo de Struts funcione sin modificaciones. Esto se manifiesta como un error JSP cuando intentamos acceder a la aplicación de ejemplo, con el siguiente mensaje:
javax.servlet.jsp.JspException: Missing
resources
attributeorg.apache.struts.action.MESSAGE
seguido por seguimietno de error. También habrá un mensaje de error de inicialización en el fichero de log ORION_HOME/log/global-application.log. Para evitar este probelma, podemos seguir estos pasos:
- Vamos al directorio $STRUTS_HOME/webapps, donde observamos que Orion ha expandido automáticamente cada aplicación web en una estructura de directorios descomprimida.
- Vamos al directorio $STRUTS_HOME/webapps/struts-example/WEB-INF, y copiamos el fichero struts-config.xml un directorio más arriba (es decir, dentro de $STRUTS_HOME/webapps/struts-example).
- Modificamos el fichero $STRUTS_HOME/webapps/struts-example/WEB-INF/web.xm, cambiando el valor del parámetro "config" (para el servlet action) de /WEB-INF/struts-config.xml a /action.xml.
- Reiniciamos Orion, y deberíamos poder acceder a la aplicación de ejemplo.
- Observa que este atajo tiene un efecto colateral negativo con respecto al a seguridad: nuestro fichero struts-conifig.xml ahora puede ser recuperado por clientes remotos en la siguiente URL:
http://localhost/struts-example/struts-config.xml
Por lo tanto, deberíamos asegurarnos de no guardar información sensible (como passwords de bases de datos) en este fichero.
Resin 1.2+ "standalone"
No requiere pasos adicionales.
SilverStream 3.7.1 y posteriores
- Arrancamos el Servidor de Aplicaciones SilverStream.
- Creamos un plan de despliegue XML para la aplicación "struts-example.war". Llamamos al fichero "struts-example-depl-plan.xml". Podemos usar los siguientes contenidos para el fichero:
----- cut here -----
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE warJarOptions PUBLIC
"-//SilverStream Software, Inc.//DTD J2EE WAR Deployment Plan//EN"
"deploy_war.dtd">
<warJarOptions>
<warJar>
<warJarName>struts-example.war</warJarName>
<isEnabled>true</isEnabled>
<urls><el>struts-example</el></urls>
</warJar>
</warJarOptions>
----- cut here -----
- Creamos un plan de despliegue XML para la aplicación "struts-documentation.war". Llamamos al fichero
"struts-documentation-depl-plan.xml". Podemos usar los siguientes contenidos para el fichero:
---- cut here -----
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE warJarOptions PUBLIC
"-//SilverStream Software, Inc.//DTD J2EE WAR Deployment Plan//EN"
"deploy_war.dtd">
<warJarOptions>
<warJar>
<warJarName>struts-documentation.war</warJarName>
<isEnabled>true</isEnabled>
<urls><el>struts-documentation</el></urls>
</warJar>
</warJarOptions>
----- cut here -----
- Ejecutamos los siguientes comandos "SilverCmd DeployWAR" para desplegar las aplicaciones. Podemos cambiar 'localhost' por el servidor en el que estemos desplegando. También podemos cambiar 'Silvermaster' por la base de datos que estamos desplegando:
SilverCmd DeployWar localhost Silvermaster
Struts-example.war -f Struts-example-depl-plan.xml
SilverCmd DeployWar localhost Silvermaster
Struts-documentation.war -f Struts-documentation-depl-plan.xml
Tomcat 3.1 y Anteriores
No recomendados, usar Tomcat 3.2.1 o posteriores.
Tomcat 3.2.1 con Apache
Observa que las instrucciones para Tomcat 4 serán diferentes de las de Tomcat 3, pero el conector web de Tomcat 4.0 todavía está en desarrollo. Las versiones de Tomcat anteriores a la 3.2.1 no se recomiendan para su uso com Struts.
Estas instrucciones asumen que hemos integrado perfectamente Tomcat con Apache de acuerdo a la documentación de Tomcat.
- Copiamos "struts-documentation.war" y "struts-example.war" a nuestro directorio $TOMCAT_HOME/webapps.
- Reniciamos Tomcat si se estaba ejecutando.
- Tomcat generará un fichero $TOMCAT_HOME/conf/tomcat-apache.conf que será usado por Apache. Este fichero se regenera cada vez que arrancamos Tomcat, por eso copiamos este fichero a un lugar seguro (como en nuestro directorio de configuración de Apache; sobre sistemas UNIX normalmente es /usr/local/apache/conf.
- Si estámos ejecutando Tomcat 3.1, no generará las entradas para nuestras nuevas aplicaciones. Añadimos las siguientes líneas al fichero tomcat-apache.conf que hemos grabado, reemplazando $TOMCAT_HOME con el path de nuestro directorio home de Tomcat:
Alias /struts-documentation "$TOMCAT_HOME/webapps/struts-documentation
<Directory "$TOMCAT_HOME/webapps/struts-documentation>
Options Indexes FollowSymLinks
</Directory>
ApJServMount /struts-documentation/servlet /struts-documentation
<Location "/struts-documentation/WEB-INF/">
AllowOverride None
deny from all
</Location>
Alias /struts-example "$TOMCAT_HOME/webapps/struts-example"
<Directory "$TOMCAT_HOME/webapps/struts-example>
Options Indexes FollowSymLinks
</Directory>
ApJServMount /struts-example/servlet /struts-example
<Location "/struts-example/WEB-INF/">
AllowOverride None
deny from all
</Location>
- El fichero generado arriba no sabe nada sobre los mapeos de extensión definidos en un fichero web.xml, por eso, las URIs "*.do" que vayan al servlet controlador no serán reconicidas. Para corregir esto, añadimos la siguiente línea a la versión grabada de "tomcat-apache.conf", depués de la línea correspondiente a la extensión .jsp:
AddHandler jserv-servlet .do
- Nos aseguramos de que la versión grabada de "tomcat-apache.conf" es referenciada en nuestro fichero de configuración de Apache httpd.conf. Un uso típico sería tener la siguiente línea en la parte inferior de httpd.conf:
Include
/usr/local/apache/conf/tomcat-apache.conf
- Para poder reconocer index.jsp como la página por defecto para aplicaciones web, buscamos en nuestro httpd.conf una directiva DirectoryIndex. Si tenemos una. añadimos index.jsp al final de la lista, que se podría parecer a esta:
DirectoryIndex
index.html index.jsp
Si no tenemos dicha entrada, añadimos una como esta:
DirectoryIndex index.jsp
- Reiniciamos Apache para hacer que tenga en cuenta las nuevas aplicaciones. Ahora deberíamos poder acceder a las aplicacioens desde un navegador con estas URLs:
http://localhost/struts-documentation
http://localhost/struts-example
Tomcat 3.2.1 + "standalone"
No requiere pasos adicionales.
Tomcat 4.0
No requiere pasos adicionales.
Weblogic 5.1 (Service Pck 8)
- Obtener e instalar el analizador XML Xerces (se han reportado problemas con la implementación de referencia de Sun). Poner xerces.jar en el path de nuestro sistema WebLogic.
- Obtener y despempaquetar la distribución binaria de Struts (esto procedimiento asume que se ha extraído en c:\jakarta-struts).
- añadir una entrada la fichero weblogic.properties por cada aplicación web Struts que queramos configurar. Por ejemplo, para hacer disponible la aplicación struts-example añadimos la siguiente línea a weblogic.properties:
weblogic.httpd.webApp.strutsexample=
c:/jakarta-struts/webapps/struts-example.war
- No necesitamos incluir struts.jar o cualquier de las clases específicas de la aplicación en el classpath de WebLogic, ya que se esto se hará automáticamente (a menos que despleguemos un archivo web desempaquetado).
- Arrancamos el Servidor WebLogic y apuntamos nuestro navegador web a la aplicación Struts. Por ejemplo, para conectar con el aplicación de ejemplo añadida en el paso anterior:
http://localhost:7001/strutsexample
- Esta aplicación de ejemplo depende de que esté presente el fichero de recursos específicos de Struts ApplicationResources.properties en el classpath. Sin embargo, WebLogic, sólo extrae los ficheros *.class desde el archivo por eso este fichero no será encontrado, resultando en un error la primera vez que sea necesitado-- algo similar a:
javax.servlet.ServletException: runtime failure in custom tag
'message'.
- Extraemos el fichero ApplicationResources.properties desde el fichero *.war, y lo copiamos manualmente en el directorio _tmp_war_ WebLogic creado para esta aplicación. De nuevo, refiriendose a la aplicación struts-example, esto sería:
c:\jakarta-struts\webapps\WEB-INF\_tmp_war_strutsexample
- Reiniciamos webLogic. Ahora podemos ejecutar la aplicación:
http://localhost:7001/strutsexample
Los pasos de arriba se deberían seguir para aplicaciones desplegadas como ficheros *.war. Para aplicaciones web desempaquetadas, la configuracion implica añadir struts.jar y /WEB-INF/classes al claspath de WebLogic. Por esta razon, sugiero desplegar las aplicaciones como ficheros war en WebLogic. Sin embargo la misma aplicación de ejemplo puede desplegarse satisfactoriamente en formato expandido modificando weblogic.properties (asumiendo que el fichero war fue estraído al directorio webapps/struts-example):
weblogic.httpd.webApp.strutsexample=
c:/jakarta-struts/webapps/struts-example/
Y arrancado WebLogic con el classpath actualizado. Por ejemplo:
c:\jdk1.3\bin\java -ms16m -mx64m
-classpath c:\weblogic\lib\weblogic510sp8boot.jar;
Recomendaciones Adicionales
- Se debería desactivar la recarga de Servlets y JSP. Primero, lo pagamos con una bajada de rendimiento. Dependiendo del número de JSPs, el número de solicitudes y el intervalo de chequeo configurado, el servidor irá más lento. Segundo, con la recarga de JSP y servlets, uno abre la puerta de varios problemas de los cargadores de clases WebLogic, que son díficiles de diagnosticar, díficiles de manejar y frecuentemente acaban con la perdida de sesiones HTTP.
- Seleccionamos el nombre de la sessionid a JSESSIONID, si se usan las cookies para el seguimiento de sesión y a jsessionid, si las sesiones están basadas en URL. (Hay problemas adicionales relacionados con las sesiones basadas en URL, cuasados por la forma en que BEA codifica el id de la sesión (incompatible con J2EE). Especialmente <bean:include> no funcionará con sesiones basadas en URL. Sin embargo, usar el nombre de sesión correcto resolverá alguno de estos problemas).
- Configuramos el registro JSP-Servlet en weblogic.properties para una compatibilidad máxima con J2EE y/o un rendimiento máximo.
El JSP-Servlet soporta algunos parámetros de inicialización que pueden ser personalizados para obtener un mejor rendimiento, o una mejor depuración:
weblogic.httpd.initArgs.*.jsp=\
pageCheckSeconds=-1,\
setEmptyStrings=false,\
compileCommand=./_jspCompiler_.cmd,\
workingDir=/weblogic/myserver/tmp_classfiles,\
keepgenerated=true,\
debug=true,\
verbose=true
En el ejemplo de arriba, el fichero batch (_jspCompiler_.cmd) invoca a jikes lo que resulta en un tiempo de arrancada mucho más rápido (jikes es como tres veces más rápido que javac). El fichero batch contiene una sóla línea
@jikes -g -nowarn %*
Se podría utilizar las siguiente configuración cuando se hayan hecho todos los test y una velocidad mayor sea primordial:
weblogic.httpd.initArgs.*.jsp=\
pageCheckSeconds=-1,\
setEmptyStrings=false,\
compileCommand=./_jspCompiler_.cmd,\
workingDir=/weblogic/myserver/tmp_classfiles,\
keepgenerated=false,\
debug=false,\
verbose=false
... junto con ...
@jikes -O -nowarn %*
Weblogic soporta selecciones similares a través de <context-params> en web.xml (Por favor lee los detalles en la última documentación en la site de BEA).
WebLogic 6.0+
No requiere pasos adicionales.
WebSphere Application Server 3.5 FixPack 2
- En los pasos de abajo, $WAS_HOME se refiere al directorio en que hemos instalado el servidor de aplicaciones WebSphere, y $STRUTS_HOME es el directorio donde hemos desempaquetado la distribución binaria de Struts.
- WebSphere anteriores a 3.5.2 no soportaban JSP 1.1 y Servlet 2.2, lo que hacía dificil obtener las funcionalidades de Struts sin masivos cambios de código. Por favor actualiza a 3.5.2 (3.5 con FixPack 2) antes de intentar usar Struts. Puedes ver en http://www.ibm.com/software/webservers/appserv/efix.html como descargar e instalar FixPack 2 para WebSphere 3.5.
- Aviso: Struts no funcionará con WebSphere 3.5.2 sin modificaciones. Se espera que se hagan las correcciones en WebSphere 3.5.3. Sin embargo, podemos hacer que WebSphere 3.5.2 funcione con Struts.
- Nos aseguramos de que está arrancado WebSphere Application Server. Bajo Windows NT/2000, es el servicio "IBM WS AdminServer".
- Arrancamos la Consola Administrativa de WebSphere.
- Una vez arrancada, seleccionamos Convert a War File de la opción de la barra de tareas, o desde el menú Console->Tasks. Esto hará que se muestre un diálogo del Wizard Convert War File.
- Seleccionamos un Servlet Engine para hospedar la aplicación Web que resultará de la conversión del fichero War, por ejemplo, Default Servlet Engine, expandiendo el árbol de control bajo los nodos; y pulsamos el botón Next.
- Seleccionamos un Host virtual para asociarlos con la aplicación web resultante, por ejemplo, default host. Pulsamos el botón Next.
- Pulsamos el botón Browse y elegimos el $STRUTS_HOME/webapps/struts-example.war. Pulsamos el botón Next.
- Seleccionamos un directorio de destino para la aplicación web resultante, por ejemplo $WAS_HOME/hosts/default_host. Pulsamos el botón Next.
- Introducimos un Web Application Web Path, por ejemplo, struts-example, y un Web Application Name, por ejemplo, struts-example. Pulsamos el botón Finish.
- Después de una ligera pausa, deberíamos obtener un mensaje con el texto Command "convert war file" completed successfully. Pulsamos Ok.
- Ahora necesitamos añadir jaxp.jar y un analizador compatible jaxp, por ejemplo, parser.jar desde JAXP 1.0.1 al directorio del a aplicación web, por ejemplo, $WAS_HOME/AppServer/hosts/default_host/struts-example/servlets.
- En este punto, si WAS 3.5.2 implementara correctamente Servlet 2.2, todo iría bien. Sin embargo, WAS 3.5.2 devuelve null para las llamadas a ServletContext.getResource(String) o ServletContext.getResourceAsStream(String). Esto se manifiesta como una excepción en la salida del servidor de aplicación, por ejemplo default_server_stdout.log..
- Cuidado, creamos en el hecho de que la aplicación web arranca satisfactoriamente desde la Consola de Administración. Realmente no lo hace. La consola de Administración está mintiendo. Si intentamos acceder a webapp por ejemplo, http://localhost/struts-example/ fallará.
- En este punto, necesitamos parchear el código fuente de Struts, Hay tres lugares donde se llama a getResourceAsStream:
ResourceTag.doStartTag()
ActionServlet.initMapping()
PropertyMessageResources.loadLocale(String)
de estos, ActionServlet es el más importante.
- Cambiamos la fuente de
// Acquire an input stream to our configuration resource
InputStream input = getServletContext().getResourceAsStream(config);
a
// Acquire an input stream to our configuration resource
InputStream input = new
java.io.FileInputStream(getServletContext().getRealPath(config));
- Hacemos cambios similares para las otras clases si es necesario.
- Recompilamos ActionServlet y copiamos el fichero .class a
$WAS_HOME/AppServer/hosts/default_host/struts-example/servlets/
org/apache/struts/action/ActionServlet.class
- Otro bug con el cargador de clases de WAS 3.5.2 es que la clase Class.getResource() no carga un recurso desde un jar, por eso debemos copiar $STRUTS_HOME/lib/struts-config_1_0.dtd a $WAS_HOME/AppServer/hosts/default_host/struts-example/servlets/org/apache/struts/resources/struts-config_1_0.dtd
o conectar a Internet para obtener el dtd desde la web site de jakarta.
- Arrancamos nuestro webapp en la Consola de Administración.
- Probamos la aplicación de ejmplo cargando la siguiente URL en nuestra navegador:
http://localhost/struts-example/
WebSphere - Pasos para la Aplicación de Ejemplo
Servidor: Windows 2000 Server con WebSphere 3.5.3 Advanced
- Arrancamos el adminserver.
- Arrancamos la Consola de Administración.
- Usamos la tarea Convert War file para convertir el struts-example.war.
- Lo convertimos a default_server, el motor servlet por defecto y el directorio de instalación estándard (c:\websphere\appserver\hosts\default_host).
- Creamos un directorio WEB-INF en el directorio servlets y copiamos struts-config.xml, database.xml y web.xml dentro de el (mantener WEB-INF con todas las TLD's bajo web - ambos directorios WEB-INF deben estar presentes).
- Copiamos jaxp 1.0.1' (No 1.1.1's) jaxp.jar y parser.jar al directorio servlets de la aplicación strut-example.
- En el directorio Servelts, abrimos struts.jar con WinZip. Extraemos los tres DTDs (struts-config_1_0.dtd, web-app_2_2.dtd y web-app_2_3.dtd) dentro del directorio servlets asegurándonos de que usamos nombres de carpetas (para que los ficheros se extraigan a servlets/org/apache/struts/resources).
- Pulsamos sobre struts-example en la Consola de Administración bajo Default Server/Default Servlet Engine y pulsamos la pestaña advanced en el lado derecho de la pantalla.
- Debajo de donde dice Default Error Page, introducimos /ErrorReporter y pulsamos Apply.
- Arrancamos el Default Server mediante la Consola de Administración. Deberíamos ver un mensaje de ActionServlet en el fichero default_host_stdout.log sin ninguna excepcion.
- Mediante un navegador accedemos a la aplicación usando: http://localhost/struts-example/index.jsp.
- Si devuelve Application not Available volvemos a la consola de administración, pulsamos con el botón derecho sobre struts-example y seleccionamos Restart WebApp.
- Una vez que veamos el informe de éxtio, vamos de nuevo a la URL de arriba y lo intentamos de nuevo -- debería funcionar sin problemas.
Por alguna razón, a algunas instalaciones no les gustan los ficheros XML que referencian DTDs públicas -- si miramos el fichero default_host_stdout.log veremos errores sobre referencias a URL públicas inválidas durante los registros DTD, o si nuestra página dice cannot find //logon o //saveRegistration (por ejemplo mapeos de acciones) hacemos los siguiente:
- Paramos el servidor por defecto.
- Vamos a servlets\WEB-INF\ y editamos web.xml y struts_config.xml.
- En la declaración DOCTYPE, cambiamos la palabra PUBLIC por SYSTEM y eliminamos completamente la línea que dice:
-//Sun Microsystems,Inc.//DTD Web Application 2.2//EN
de web.xml y
-//Apache Software Foundation//DTD Struts Configuration 1.0//EN
de struts-config.xml.
- Grabamos estos ficheros y vamos de nuevo al paso 10 de arriba.
Tutoriales
