{scrollbar}

top

Algunos cambios introducidos en esta nueva versión, afectan la configuración y planes de activación de instalaciones existentes. En esta sección nos enfocaremos en la distinción de dichas diferencias, en el como aplicar los cambios necesarios, así como en algunas herramientas de auxilio de migración (en caso de estar disponibles).

Los cambios en relación a la v1.0 con respecto a esta nueva versión, no sólo estan limitados a planes de activación, como se mencionó en la sección de Resumen de cambios

Usando la herramienta de actualización

Puedes emplear la herramienta de actualización para migrar tus planes geronimo de 1.0 a 1.1. Para usar la herramienta de actualización, desde el directorio <geronimo_home>\bin ejecuta:
java -jar upgrade.jar

Parámetros posibles:
planDeEntrada planDeSalida
ó
planDeEntrada
caso en el cual el plan de salida estará en la misma ubicación que el plan de entrada, con '.upgraded' en su nombre.

Después de que corres la herramienta de actualización, existen algunos pasos adicionales si tu aplicación emplea base de datos ó JMS:

1) Agrega manualmente la base de datos ó al módulo rar JMS como dependencia:

Si la aplicación usa referencia de recursos en 1.1, las referencias de recursos deben poder ser resueltas en el grupo de ancestros de tu módulo. En otras palabras, tu aplicación debe depender de la activación del rar.

Ejemplo:

xmlsolid

<sys:dependencies> <sys:dependency> <sys:groupId>Ejemplo</ sys:groupId> <sys:artifactId>DatasourceEmpleado</sys:artifactId> <sys:version>1.1</ sys:version> <sys:type>rar</ sys:type> </sys:dependency> </sys:dependencies>

Sin especificar la dependencia, podrías obtener al siguiente error ante la activación de tu aplicación:

solid

> ------------------------------------------------------ > Error: Unable to distribute XXX: Unable to resolve > resource reference 'XXX' (Could not find resource > 'XXX'. Perhaps it has not yet been configured, > or your application does not have a dependency declared for that > resource module?)

2) Convertir manualmente las dependencias derby jar a datasource-sistema:

Si tu plan de connection pool 1.0 de base de datos tiene lo siguiente como dependencias:

xmlsolid

<dependency> <uri>org.apache.derby/derby/10.1.1.0/jar</uri> </dependency> <dependency> <uri>org.apache.derby/derbynet/10.1.1.0/jar</uri> </dependency>

La herramienta de actualización les convertirá a:

xmlsolid

<dep:dependency> <dep:groupId>org.apache.derby</dep:groupId> <dep:artifactId>derby</dep:artifactId> <dep:version>10.1.1.0</dep:version> <dep:type>jar</dep:type> </dep:dependency> <dep:dependency> <dep:groupId>org.apache.derby</dep:groupId> <dep:artifactId>derbynet</dep:artifactId> <dep:version>10.1.1.0</dep:version> <dep:type>jar</dep:type> </dep:dependency>

Sin embargo, lo anterior carga una segunda copia de derby en un segundo classloader, lo que te causará el siguiente error cuando ejecutes tu aplicación:

SQL Exception: Failed to start database 'XXX', see the next exception for details.

En su lugar, necesitas una dependencia car en datasource-sistema, para que compartas su copia de derby.

xmlsolid

<dep:dependency> <dep:groupId>geronimo</dep:groupId> <dep:artifactId>system-database</dep:artifactId> <dep:type>car</dep:type> </dep:dependency>

Usando la consola de administración

Cuando actives una aplicación mediante la consola de administración, el portlet detectará automáticamente a un plan 1.0 e invocará la herramienta de actualizaciòn decrita previamente, para así proporcionar un plan 1.1 que puedes almacenar localmente, aplicarle ajustes si es necesario, y después usarlo para activar tu aplicación.
Actualmente la consola sólo proporciona esta funcionalidad para archivos externos de planes.