icono_twiter
Jose Manuel Sánchez Suárez

Consultor tecnológico de desarrollo de proyectos informáticos.

Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación

Somos expertos en Java/J2EE

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2009-09-14

Tutorial visitado 10.926 veces Descargar en PDF
EJB 3.0 y pruebas de persistencia con Maven, JUnit 4 y Embedded JBoss sobre Java 6.

EJB 3.0 y pruebas de persistencia con Maven, JUnit 4 y Embedded JBoss sobre Java 6.


0. Índice de contenidos.


1. Introducción.

El hecho de que haya casi plagiado el título de este tutorial del de mi compi Carlos García sobre EJB 3.0 y pruebas unitarias con Maven, JUnit 4 y Embedded JBoss sobre Java 6 no es casual, puesto que lo que vamos a hacer es darle continuidad, probando ahora cómo llevar a cabo un test de persistencia de un EJB de entidad, bajo el soporte de un EJB de servicio que implementa el patrón dao, en el mismo entorno.

La configuración en el entorno de Embedded Jboss 2 ya la vimos de la mano de Alejandro, ahora se trata de comprobar si la misma funciona en el entorno de la versión 3.

Vamos a ir, sobre la base del tutorial de Carlos, paso a paso añadiendo la configuración necesaria para JPA, comentando los errores que se pueden ir produciendo y cómo darles una solución.


2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil Asus G1 (Core 2 Duo a 2.1 GHz, 2048 MB RAM, 120 GB HD).
  • Sistema operativo: Windows Vista Ultimate.
  • JDK 1.6.0_14
  • Maven 2.1.
  • Embedded Jboss beta3.SP10

3. La capa de persistencia.

La capa de persistencia se va a componer de un EJB de entidad y uno de servicio sin estado que expone una interfaz local.

User.java: el EJB de entidad.

Dao.java: el interfaz de EJB Local.

GenericDao.java: el EJB de servicio que expone la interfaz Local.

Estas clases se ubicarán bajo la carpeta src/main/java, puesto que son clases de aplicación y para que compilen necesitaremos añadir la dependencia al siguiente artefacto en el pom.xml:

El test es el siguiente. Muestro sólo el método, puesto que la clase que tiene el soporte para levantar el Embedded Jboss, la podéis encontrar en el tutorial de Carlos. Estará ubicado bajo la carpeta src/test/java:

Si ejecutamos el test sin más, se producirá la siguiente excepción:

puesto que es necesario añadir, al jar que se despliega, las clases con las que estamos trabajando:

Si os parece tedioso añadir una a una las clases necesarias, existe, entre otros, un método como el que sigue, que añade todas las clases de un paquete raíz a partir del package de la clase que se pasa como primer parámetro:


4. Configuración de la unidad de persistencia.

En este punto el test aún no pasa, se debería producir la siguiente excepción:

Nos falta un fichero persistence.xml en el que definiremos la unidad de persistencia:

  • src/main/resources/META-INF/persistence.xml: con la configuración para el entorno de producción, esto es, la de la aplicación en un entorno no de tests,
  • src/test/resources/persistence-test.xml: con la configuración para el entorno de tests. El cambio de nomenclatura del fichero respecto al de producción, al anterior, viene dado porque ambos estarán en el classpath de la ejecución de los tests, de ahí que no convenga tampoco incluirlo dentro de una carpeta META-INF dentro de resources, para que no colisionen.

El contenido del fichero persistence-test.xml, podría ser como sigue:

La fuente de datos DefaultDS se incluye por defecto en el entorno de Embedded Jboss, la podéis encontrar en \src\test\resources\deploy\hsqldb-ds.xml, y configura una base de datos hsqldb.

Simplemente con incluir el fichero persistence-test.xml al directorio de resources no funciona puesto que tenemos que añadirlo al jar que se despliega. Así creammos un directorio de ensamblado que se llame META-INF dentro del jar y añadimos el fichero sin el path:

En este punto, ejecutando el test desde Eclipse con la propiedad "-Dsun.lang.ClassLoader.allowArraySyntax=true" asignada en el arranque de la VM, debería funcionar correctamente, aunque suelta la siguiente traza a nivel de warning:

Si bien, con maven desde línea de comandos, deberíamos tener esta maravillosa excepción:

vfs o Virtual File System es una abstracción de un sistema de ficheros, precisamente el que se crea para ensamblar el jar y el número es el nombre del mismo.

Pero... ¿cuál es el problema?

  • parece que el encargado de desplegar la unidad de persistencia ahora no soporta este sistema de ficheros, puesto que en la versión 2 de Embedded Jboss no teníamos este problema,
  • pero ¿será una problema de classpath?, puesto que desde el entorno de Eclipse no se reproduce.
  • ¿habrá sido al subir de versión la JDK?, no, porque es la misma que la del Eclipse, la 1.6, y ahí sí funciona,
  • ...

Como hemos comentado en el resto de tutoriales sobre Embedded Jboss, está aún en versión beta, la documentación es escasa y las respuestas en los foros a las cuestiones que se plantean no son de mucha calidad.

La casuística de nuestro error es la misma que se describe en este post del foro de Jboss, y la solución que le dan pasa por dejar de usar el directorio virtual y realizar un scan de un directorio físico para que monte todo lo que se encuentre dentro de él.

También se podría incluir algo como lo que sigue, que permite desplegar las librerías que contegan el recurso que recibe como parámetro.

Y el caso es que ambas soluciones funcionan, pero no es lo que queremos puesto que está levantando la unidad de persistencia que se encuentra en el directorio src/main/resources/META-INF, se podría parchear en base a mover ficheros de un sitio a otro con la ayuda del plugin de resources de maven, pero estaríamos complicandolo más aún. Hay que poner especial cuidado en revisar la siguiente traza para comprobar qué unidad de persistencia está levantando:



5. Ejecución del test desde maven.

Entonces... ¿qué diferencia existe entre la ejecución desde Eclipse y con maven desde línea de comandos?, la respuesta es sencilla, aunque ha costado algo más de lo deseado encontrarla.

El plugin de surefire es el encargado de ejecutar los tests en el entorno de maven y por defecto tiene activa la propiedad enableAssertions que habilita las aserciones de la JVM en la ejecución de los tests, modificando el comportamiento por defecto de la JVM, que lo tiene desactivado y que es como se ecuentra en el entorno de ejecución desde Eclipse.

Las asercciones o asertos son instrucciones del propio lenguaje Java, que permiten poner a prueba suposiciones dentro de la lógica de un programa. La lógica es la misma de los Assert.assert de los tests de Junit, pero forman parte del propio lenguaje, con lo que los evalúa la propia JVM en tiempo de ejecución.

El último de los tres ejemplos anteriores es precisamente el código que está lanzando la excepción en la ejecución del test que nos ocupa, ejecutando maven por línea de comandos, y el caso es que la aserción no debe ser tal, o no tan importante, puesto que desde Eclipse el test funciona y deshabilitando los assert en el plugin de surefire también.

Deshabilitando la propiedad enableAssertions, el test funciona, aunque seguimos teniendo la traza a nivel de warning que comentábamos más arriba. Existe un hilo en el foro de Jboss donde tratan el tema, pero no parece que sea demasiado relevante puesto que se trata de un error al abrir el directorio virtual, seguramente producido por no estar activo el assert. El caso es que se realiza un scan en busca de clases anotadas, y se produce esa excepción. Como nosotros las incluimos en el persistence.xml no pasa de ser un warning.

Por último, hemos comprobado que bajo una versión 1.5 de Java los tests también pasan, con el mismo warning.


9. Conclusiones.

Recordar que Embedded Jboss sigue en versión beta y ya lleva unos años así, y este tipo de problemas con la subida de versiones los tenemos que ir asumiendo. Al subir de versión una aplicación, tendremos que adaptar el entorno de pruebas si es necesario, pero puede ocurrirnos lo contrario, que no podamos subir de versión la tecnología de una aplicación porque no está soportada en el entorno de pruebas.

Por otro lado, si cuando comenzamos con Embeded Jboss era la única solución disponible para hacer uso de un micro-contenedor de EJBs en el entorno de nuestros tests, hoy día existen más y alguna bastante interesante como Apache Open EJB, que iremos evaluando, en breve.

Un saludo.

Jose

mailto:jmsanchez@autentia.com

A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL: