Compartir Recursos en MyMobileWeb
De MorfeoWiki
Contenido |
Compartir Recursos en MyMobileWeb
- Autor: Javier de la Rosa, jrosa@yaco.es, Yaco Sistemas.
- Estado: Borrador inicial.
- Comentario: Documento en estado inicial con una visión subjetiva por parte de un desarrollador usuario de la plataforma que trabaja en entornos Linux. El código que contiene este documento no está testado ni ampliamente probado, por lo que el autor no se hace responsable de los efectos de uso que conlleve, pidiendo además colaboración en la corrección de los fallos que puedan derivarse.
- Revisado: Cristian Rodríguez, crc39@tid.es, TID
Introducción
Uno de los problemas de MyMobileWeb se nos presenta a la hora de implantar un entorno de producción en el que concurran una buena cantidad de aplicaciones web generadas por la plataforma (un supuesto de alrededor de 1,000), y es que MyMobileWeb presenta carencias a este respecto, por lo que hay recursos que deberían estar compartidos y que no lo están. Este documento está divido en tres partes: una primera en la que se comentan modificaciones en la configuración que permiten ahorrar espacio y compartir los recursos, y otra en la que se dan unas directrices deseadas para hacer de esta característica algo habitual del sistema y parte de su comportamiento base. Por último, se hace una aproximación a la metodología de trabajo actual seguida por el autor.
Compartir recursos
Se da por sentado una correcta configuración de Java, sus variables de entorno para Java Servlets y Apache Tomcat 5.5, así como una versión actualizada de DeployTools en /opt/DeployTools. Con esto, el procedimiento para generar aplicaciones que minimicen los recursos es el siguiente:
- Reutilizar las librerías de la plataforma; para lo cual la configuración ha de ser la misma tanto en el entorno de desarrollo como en el de producción. Existen dos opciones:
- Colocar las librerías bajo el directorio /lib del servidor de aplicaciones Apache Tomcat, típicamente /var/lib/tomcat5.5/common/lib. Si el servidor va a ser utilizado exclusivamente para MyMobileWeb esta es la mejor solución, puesto que de lo contrario se cargaría una buena de cantidad de librerías que no serían utilizadas por todas las aplicaciones, con el consecuente gasto de rendimiento, tiempo y memoria.
- Situarlas en un directorio específico, por ejemplo en el que vienen por defecto en DeployTools/lib, y crear enlaces simbólicos a la ruta absoluta en la aplicación.
-
ln -s /opt/DeployTools/lib /ruta/de/la/aplicación/WEB-INF/lib
-
- Otra opción sería enlazarlo directamente en el directorio /lib de Apache Tomcat. No obstante, pese a la facilidad y elegancia de los enlaces, no está verificado su funcionamiento en el caso de sistemas Windows (instrucción mklink)
- Por supuesto, cualquier otra librería necesaria, como las de manejo de base de datos PostgreSQL, también tendría que ser copiada/enlazada.
- Además aquí se presenta la dificultad de no ser las mismas librerías las existentes en DeployTools/lib que en template-project/WEB-INF/lib, por lo que es una aspecto a tener en cuenta. Esto no es problema porque en producción las librerías del DeployTools no son necesarias, las librerías de ejecución sólo son las del template/WEB-INF/lib
- Compartir la base de datos de dispositivos. Editar el fichero MyMobileWeb.DevMng.xml, la propiedad dataBaseDirectory y colocar una ruta accesible en la que se deese compartir la información sobre dispositivos. Perfecto, así lo tenemos nosotros las demos de MyMobileWeb
-
<property name = "dataBaseDirectory" value="/opt/DeployTools/DeviceBBDD"/>
-
Por cierto no confundir esto, la base de datos de dispositivos nada tiene que ver con las herramientas de despliegue
<property name = "dataBaseDirectory" value="/opt/MyMobileWeb/DeviceBBDD"/>
Wishlist
- En primera instancia, sería deseable disponer de un directorio subversion sobre el cual hacer check out (y posteriormente update) y así obtener todo lo necesario para la generación de aplicaciones totalmente actualizado (al estilo de Django), lo que sería mucho más útil y práctico que descargarse una nighty build, descomprimirla, colocar los ficheros en su ubicación, y reemplazar los .jar actualizados para regenerar las aplicaciones. De esta manera, teniendo en cuenta lo anterior sobre compartir recursos, bastaría con hacer una vez cada dos días una simple sentencia
svn upy ya se tendría el entorno actualizado. También es posible, sin mucho esfuerzo, utilizar las herramientas generator.sh y ocawar.sh para regenerar las aplicaciones que se deseen sin necesidad de abrir el entorno Eclipse y hacer la generación a mano.
- Asimismo, sería deseable eliminar las diferencias existentes entre el directorio /lib de DeployTools y de WEB-INF/lib del template-project, yendo aún más allá y modificando en la plantilla el directorio /lib consecuentemente para facilitar la compartición de recursos.
Es que nada tienen que ver la herramienta de despliegue de presentaciones y extracción de literales (DeployTools) en momento de desarrollo , con las librerías de ejecución.
- Problemas similares encontramos en los recursos de la aplicación:
- Los recursos como imágenes están en la misma ubicación que los recursos propios de la plataforma.
Se podrá hacer que los recursos de imágenes de plataforma sean compartidos por todas las aplicaciones. Para ello se ha de crear una propiedad a mayores, una la path de las imágenes de la propia aplicación y otra path absoluta de las imágenes de plataforma
- Ídem para con los literales de la plataforma.
Lo mismo que para el caso anterior, es viable también
- La solución podría pasar por separar tanto los recursos como los literales de la plataforma de los de la aplicación, colocando los primeros a partir de /opt/DeployTools y dejando los últimos en su ubicación actual. Quizás sería conveniente para ello crear entradas en los ficheros de configuración que permitan especificar las rutas tanto para recursos y literales de la plataforma como para los de la aplicación
El mismo tratamiento que para literales adoptariamos para los mensajes
Metodología de trabajo
Disponemos por defecto de el Entorno de Desarrollo Integrado Eclipse con su Plugin de Tomcat. Basándonos en el método de trabajo, esto es, la imposibilidad real de trabajar simultáneamente en más de una aplicación MyMobileWeb y el tiempo perdido configurando parámetros en su fase inicial, hemos desarrollado un script en python que configura automáticamente la mayoría de los parámetros para su correcta generación por parte de la plataforma. Debido a que su funcionamiento no es eficiente, ya que está basado en expresiones regulares y reemplazo de texto en lugar de edición del árbol XML de los ficheros, no se comentará extensamente y únicamente lo dejaré enlazado como adjunto (codegen.py), dejando para una versión posterior una buena implementación de esta idea. Además, para que esta herramienta funcione, ha de modificarse el fichero generator.sh de la siguiente manera:
if [ -z "$JAVA_HOME" ]; then echo "You must be set the environment variable JAVA_HOME" echo elif [ -z "$MYMOBILEWEB_JSPGEN_HOME" ]; then echo "You must be set the environment variable MYMOBILEWEB_JSPGEN_HOME" echo else echo "Checking XML:" python $MYMOBILEWEB_JSPGEN_HOME/bin/codegen.py $1 $2 $MYMOBILEWEB_JSPGEN_HOME echo "Generator JSP: $*" $JAVA_HOME/bin/java -classpath $MYMOBILEWEB_JSPGEN_HOME/lib/batik-css.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/batik-util.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/mymw-common.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/mymw-common-plugin.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/mymw-deploytools-plugin.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/mymw-deploytools.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/mymw-propertymanager.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/jdom.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/log4j-1.2.9.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/mf-commons.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/sac.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/xalan.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/xercesImpl.jar:$MYMOBILEWEB_JSPGEN_HOME/lib/xml-apis.jar -Duser.dir=$MYMOBILEWEB_JSPGEN_HOME org.morfeo.tidmobile.transform.Generator $1 fi
Nótese el cambio al final de la última instrucción del $* original por $1.
Además, es necesario tener instalado un intérprete Python y modificar los argumentos de la External Tool de Eclipse de /${project_name} a /${project_name} ${project_loc}.
Para generar la aplicación disponemos del plugin de Tomcat para Eclipse, pero para agilizarlo todo un poco más se ha desarrollado un pequeño script en bash (ocawar.sh) que crea el fichero .war con las rutas relativas corregidas para su correcto despliegue y eliminando toda la información innecesaria. Para usar el script es necesario crear una nueva External Tool en Eclipse con la siguiente configuración:
- Location
- /opt/DeployTools/ocawar.sh
- Working Directory
- /opt/DeployTools
- Arguments
- ${project_name} ${project_loc} ${string_prompt:the path to deploy the application}
El argumento ${string_prompt:the path to deploy the application} realiza una petición al usuario solicitándole la ruta en la que será desplegada la aplicación, siendo por defecto /var/lib/tomcat5.5/webapps, valor que se toma si se deja el campo en blanco. El código de ocawar.sh se muestra a continuación.
#!/bin/sh
# The $* variables are sent by Eclipse External Tool
# $1: ${project_name}
# $2: ${project_loc}
# $3: ${string_prompt:the path to deploy the application}, ruta para el despliegue en el servidor
if [ -z $3 ]
then
PATH_TO_DEPLOY='/var/lib/tomcat5.5/webapps/'
else
PATH_TO_DEPLOY=$3
fi
echo "Exporting project..."
cp -r $2 /tmp
echo "Removing Subversion files..."
find /tmp/$1 -name \.svn | xargs rm -rf
echo "Removing traces, cache and work..."
rm -rf /tmp/$1/work/*
rm -rf /tmp/$1/cache/*
rm -rf /tmp/$1/traces/*
rm -rf /tmp/$1/OPs
rm -rf /tmp/$1/css
rm -rf /tmp/$1/WEB-INF/src
find /tmp/$1 -name $1.war | xargs rm -f $1.war
#echo "Replacing relatives paths..."
rpl -qR $2 $PATH_TO_DEPLOY$1 /tmp/$1
echo "Generating .war..."
jar c0f $2/$1.war -C /tmp/$1 .
echo "Removing temporal files..."
rm -rf /tmp/$1
echo "Finished."
Depende además de los comandos para Linux rpl y jar.