Recientemente publiqué una entrada: Aplicación CRUD con JEE7, en la que explicaba que había subido un proyecto a github: jee7-crud, con lo básico para realizar una aplicación CRUD con: JSF, EJB, JPA, JAX-RS.
Bien, acabo de actualizar jee7-crud, y le he metido herramientas básicas de testing:
JUnit
Mockito
Arquillian
Lo he preparado para que funcione con las dos herramientas de construcción de proyectos más populares actualmente: Maven y Gradle.
Este proyecto, A mi personalmente, me sirve de base para comenzar otros proyectos nuevos. Espero que os sea de alguna utilidad.
El código está basado en la siguiente entrada de Arun Gupta. Concretamente el código original se encuentra aquí. Recomiendo la lectura de la entrada entera. Me parece que hace una buena comparación entre Spring y JEE6, aunque personalmente creo que se equivoca en un aspecto. En uno de los puntos hace una comparación de rendimiento entre Glassfish+JEE6 y Glassfish+Spring. Creo que lo más fiel a la realidad sería utilizar Tomcat+Spring, ya que la aplicación programada con Spring no va a utilizar gran parte de las funcionalidades del Glassfish.
El código original viene con un sencillo CRUD sobre una entidad "Persona". Las tecnologías que se utilizan son: JSF, EJB, JPA.
El código fuente con mis modificaciones os lo podéis descargar aquí. He añadido JAX-RS para exponer un Servicio WEB REST a través de JSON.
Una vez que tengamos el código descargado podemos desplegarlo a través de nuestro IDE, o generar el WAR a través de maven (mvn package) o gradle (gradle war) y desplegarlo manualmente.
Para que la aplicación funcione será necesario configurar un Datasource en Glassfish. Tal y cómo se indica en el fichero "src/main/resources/META-INF/persistence.xml", la aplicación web se conecta al nombre JNDI "jdbc/myDataSource".
En este caso voy a explicar los pasos para crear un Datasource que se conecte a una base de datos Postgresql en Glassfish.
Una vez arrancado el glassfish vamos a http://localhost:4848 , Resources -> JDBC -> JDBC Connection Pools y pulsamos sobre el botón New.
En esta pantalla rellenamos los siguientes campos:
Pool Name: MyDatabase. Ponemos el nombre de nuestra base de datos, o el nombre que más rabia nos de.
ResourceType: javax.sql.ConnectionPoolDatasource
Database Driver Vendor: Postgresql
y pulsamos sobre Next. La parte superior de la siguiente pantalla tiene que quedar como en la siguiente imagen. No tocamos nada.
En la parte inferior tendremos que configurar las siguientes propiedades de conexión con nuestra base de datos:
User
DatabaseName
Password
ServerName
PortNumber. El puerto por defecto del postgresql es 5432
Al pulsar sobre "Finish" ya tenemos nuestro pool creado. Ahora nos falta crear la entrada JNDI que conecte con el pool que hemos creado. Para ello vamos a Resources -> JDBC -> JDBC Resources.
Creamos un nuevo Resource pulsando sobre el botón "New" y configuramos los siguientes campos:
JNDI Name: jdbc/myDatasource
Pool Name: Elegimos el nombre del pool que acabamos de crear.
Una vez configurado el Datasource la aplicación web ya debería poder desplegarse y funcionar perfectamente.
Actualización: He creado un proyecto en github (android-maven-blank): Es un proyecto plantilla con lo mínimo para que funcione con las dependencias explicadas en esta entrada.
Si te gusta tener todos tus proyectos gestionados con Maven, los proyectos de Android no iban a ser menos, pero la verdad es que Google no nos lo pone nada fácil.
A continuación voy a poner los pasos que he seguido para tener un proyecto de Android con las siguientes dependencias:
Y por supuesto, tener automatizado el proceso de generar el apk final que se subiría al play store.
Vamos a ponernos manos a la obra.
Pasos Previos
Las dependencias más complicadas de incluir van a ser precisamente las de Google, ya que no tiene un repositorio donde mantenga estos proyectos vía Maven. Por ello, lo primero que hay que hacer es descargarnos TODOS los extras del SDK Manager e instalarlos como módulos en nuestro repositorio local.
Después nos descargamos el proyecto maven-android-sdk-deployer, que se encargará de instalar todo en nuestro repositorio local. Una vez descargado nos ponemos en el directorio raíz y ejecutamos:
mvn install -P 2.2
(En mi caso pongo 2.2, porque es un SDK que tengo descargado).
Paso previo sólo si se va a utilizar Google Maps
Por lo que he visto, el proyecto maven-android-sdk-deployer despliega el módulo google-play-services, pero no lo instala correctamente porque no incluye el jar google-play-services_lib\libs\google-play-services.jar. Esto es así porque recientemente el SDK Manager ha cambiado la forma en la que distribuye este módulo. Seguro que dentro de poco el proyecto maven-android-sdk-deployer se modificará para que este paso previo no sea necesario.
Lo que he hecho para solucionarlo es instalar este jar manualmente como un módulo jar de maven:
Por supuesto que donde he puesto (PATH_SDK, NOMBRE_EMULADOR, RUTA_KEYSTORE, STOREPASS, KEYPASS, ALIAS) tendréis que poner vuestros valores.
Generar APK final para el Play Store
Una vez tenemos el pom.xml bien configurado, para generar el apk final tendremos que ejecutar:
mvn clean package -P sign
y dentro del directorio target nos generará dos apk: ${project.artifactId}.apk y ${project.artifactId}-signed-aligned.apk. El que termina en signed-aligned.apk es el que tendremos que utilizar para subir al Play Store, ya que es necesario que se le haya hecho un zip-align.
En esta entrada voy a explicar cómo montar un jar que incluya varios módulos de Maven, o eligiendo los paquetes de varios módulos.
Para ello vamos a utilizar el plugin maven-assembly-plugin. Se comporta como la mayoría de los plugins, definiendo la fase en la que queremos que se ejecute y hay que enlazar con otro fichero xml aparte donde se indique exactamente el contenido de este jar.
La forma de configurar esto dentro de nuestro pom.xml es de la siguiente manera:
Como podemos ver, tenemos que darle un id a esta ejecución y apuntar al fichero donde se encontrará la descripción del ensamblaje que vamos a realizar (por convención se guardan en el directorio src/main/assembly). Después indicamos que queremos que se realice después de la fase "package".
Generar jar juntando varios modulos
Para este primer caso nos vamos a meter en el contenido del fichero “assembly-nuevojar.xml”. Lo vamos a definir para que incluya las clases de 3 módulos nuestros:
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> nuevojar jar
Estamos utilizando DependencySet. Con esto le indicamos que vamos a incluir en este nuevo jar el contenido de las clases de Module1, Module2 y Module3. En mi caso se encuentran bajo el mismo proyecto, y con el useProjectArtifact le indicamos que coja las de la ejecución en la que nos encontramos.
Es muy importante, que para que esto funcione las dependencias que estamos utilizando estén definidas en el pom.xml, y no vale con que estén como provided. Sino es así nos podemos encontrar con un error.
Generar jar eligiendo paquetes concretos
Para este caso vamos a generar el jar eligiendo paquetes de diferentes módulos. En mi caso, lo he hecho de una manera que no me parece nada elegante pero me funciona, siempre y cuando los módulos a coger se encuentren en el mismo proyecto que donde se va a generar el jar.
Estamos haciendo uso del fileSet en vez del dependencySet. Con esto incluimos directamente los ficheros que queremos, en este caso las clases. Como esos modulos se encuentran dentro de nuestro mismo proyecto, ya sabemos que se encuentran bajo el directorio target/classes.
Leyendo sobre el tema he visto que esto es algo tan sencillo como duplicar los beans entityManager, entityManagerFactory y datasource con la información de conexión a la base de datos nueva. También habría que generar un nuevo persistence-unit en el fichero persistence.xml.
Después en la aplicación, suponiendo que inyectamos el EntityManager a nuestros DAOs mediante la anotación @PersistenceContext, a cada uno de ellos habría que incluirle el atributo unitName especificado en el persistence.xml:
@PersistenceContext(unitName="defaultDB")
En mi caso esto no me ha valido porque en el momento de tener que conectar otra base de datos a mi aplicación, ésta importaba una serie de librerías comunes que utilizamos para más proyectos en los que había objetos DAO con un @PersistenceContext sin especificar ningún unitName. Cambiar la librería común para que especifira el unitName es inviable ya que en cada aplicación en la que se utiliza su valor es diferente.
Al arrancar la aplicación sin hacer nada la excepción que aparece es:
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [javax.persistence.EntityManagerFactory] is defined: expected single bean but found 2 at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory(PersistenceAnnotationBeanPostProcessor.java:536)
Esta claro. El DAO que tiene el @PersistenceContext no sabe qué entityManager tiene que recibir y no podemos modificarlo para especificárselo.
En la excepción se puede ver que el error ocurre en el método findDefaultEntityManagerFactory de la clase PersistenceAnnotationBeanPostProcessor de Spring. Es el encargado de inyectar el entityManager a los @PersistenceContext.
Me he creado una clase que hereda de PersistenceAnnotationBeanPostProcessor y sobreescribe el método findDefaultEntityManagerFactory de tal manera que voy a devolver el entityManagerFactory que yo quiera. La clase en cuestión quedaría así:
public class PersistenceAnnotationBeanPostProcessor extends org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor{
public void setDefaultEntityManagerFactory( EntityManagerFactory defaultEntityManagerFactory) { this.defaultEntityManagerFactory = defaultEntityManagerFactory; }
}
Lo único que tendríamos hacer a continuación es definir un bean en la configuración de Spring con esta clase en vez de la que utiliza Spring por defecto:
Eso sí, tenemos que especificar en el atributo "defaultEntityManagerFactory" qué entityManager queremos que se inyecte cuando nos encontramos con un @PersistenceContext sin especificar un unitName.
La conexión a la segunda base de datos yo sólo la he utilizado para realizar consultas sobre ella, nunca para realizar modificaciones. No sé si habría algún fallo en las transacciones, ya que el JpaTransactionManager está ligado únicamente a un EntityManagerFactory.
En esta entrada voy a comentar una cosa bastante simple.
Cuando queremos crear un cliente de servicio web desde eclipse llegamos a un punto en el que podemos configurar un mapeo de paquetes, para que no se creen los stubs automáticamente en el paquete que le corresponda segun el namespace que venga indicado en el wsdl, sino en el sitio en el que nosotros queramos.
Esto se consigue marcando la opción "Define custom mapping for namespace to package".
Para no tener que repetir la tarea de indicar el namespace y el paquete al que queremos que se mapee, podemos crearnos un fichero de propiedades y darle al botón "Import".
Tenemos que tener en cuenta que en este fichero no podemos poner la ruta del namespace tal cual, ya que los dos puntos no lo reconoce. Lo tenemos que poner en utf8. Ejemplo:
