Accés a dades amb Java Enterprise Edition

El primer que haureu de fer serà importar la base de dades “SocIoc”, tal com es mostra en la figura.

Un cop importat, s’haurà d’haver importat el model entitat relació de la figura. El model ER de la base de dades “SocIoc” es compon de les següents taules:

• rank: serveix per guardar la puntuació que aconsegueix un alumne en base a les votacions que reben les respostes que dóna.
• questions: conté les preguntes dels alumnes.
• answers: guarda les respostes.
• votes: els alumnes que llegeixen una resposta la podran votar de forma positiva o negativa.
• users: guarda informació dels alumnes.

A continuació haureu de connectar-vos al vostre servidor MySQL per tal de crear les taules que hem definit al model ER “SocIoc”. El primer pas és crear la base de dades al servidor MySQL. Hi ha diferents formes de fer-ho, però en aquest exemple utilitzarem el client de la línia de comandes. En el cas del servidor que s’està fent servir, aquestes són les dades de connexió:

• usuari: root
• contrasenya: root
• IP del servidor: 192.168.99.100
• port: 32769

mysql  - -user=root - -password=root - -host=192.168.99.100  - -port=32769

Utilitzant Mysql Workbench, creeu una connexió amb el vostre servidor MySQL. Per fer-ho, seleccioneu Manage connections, tal com podeu veure en la figura.

A continuació afegiu les dades de connexió. En la figura podeu veure les dades de connexió al servidor local de MySQL.

Un cop està configurada la connexió ja es pot passar a exportar el model al servidor. Seleccioneu l’opció Forward Engineering del menú Database (vegeu la figura).

Seleccioneu la connexió que heu creat (vegeu la figura); en fer clic a Continue us demanarà la contrasenya per accedir a la BD.

Quant a les opcions, podeu deixar les que hi ha per defecte (vegeu la figura).

Com que només heu creat taules (vegeu la figura), només fa falta seleccionar la primera de les opcions, que exportarà les taules.

Els dos últims passos són una revisió dels scripts de creació dels objectes seleccionats (en el nostre cas, les taules). Si el procés de creació és correcte haureu de veure un missatge de confirmació com el de la figura.

Per comprovar que les taules s’han creat adequadament podeu utilitzar l’editor SQL de Workbench. Seleccioneu del menú Database l’opció Query database; després d’escollir la connexió amb la vostra BD accedireu a l’editor (vegeu la figura) i podreu executar una consulta perquè es mostrin totes les taules de la BD.

Recordeu que JPA defineix com s’ha de fer el mapatge d’objectes relacionals (ORM Object-Relational Mapping) amb la base de dades. D’aquesta forma, quan desenvolupeu una aplicació, com a programadors us podeu centrar en el codi Java i deixar que JPA s’encarregui dels detalls específics de la base de dades. Començareu creant una classe que representi un usuari de la nostra aplicació i que es pugui utilitzar per emmagatzemar dades.

Per fer això creareu una classe i l’anotareu amb l’anotació @Entity. Això transformarà una classe Java simple (POJO, Plain Old Java Object) en una EJB (Enterprise Java Bean). L’ús d’EJB permet gaudir dels serveis prestats pels servidors Java Enterprise Edition (Java EE). Hi ha diferents serveis que proporcionen el seu ús, com clustering, transaccionalitat a través de JTA, seguretat i connexions amb base de dades. A més de l’anotació @Entity hi ha altres anotacions que permeten definir quins atributs de la classe seran persistents i a quina columna de la taula seran emmagatzemats.

Un cop descarregat i descomprimit el fitxer de partida, ja el podeu importar; el nom del projecte és “UDF4-02”. En la figura es mostra on és l’opció per obrir un projecte existent.

Netbeans, en detectar el fitxer pom.xml, reconeixerà que és un projecte Maven i començarà a descarregar les dependències.

En el fitxer pom.xml de Maven, les úniques dependències que us fan falta són la del driver de la BD H2, de JUnit, javax.persistence i javax.validation. javax.persistence conté les llibreries amb totes les classes que necessitareu per treballar amb JPA. Encara que amb les llibreries de javax.persistence no necessitaríeu res més, javax.validation us aporta una sèrie d’anotacions que seran molt útils a l’hora de validar les dades que emmagatzemareu a la base de dades.

<dependencies>
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.4.190</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
      	<artifactId>junit</artifactId>
      	<version>4.12</version>
    </dependency>
    <dependency>
        <groupId>javax.persistence</groupId>
        <artifactId>persistence-api</artifactId>
        <version>1.0.2</version>
    </dependency>
    <dependency>
        <groupId>javax.validation</groupId>
        <artifactId>validation-api</artifactId>
        <version>1.1.0.Final</version>
    </dependency>
</dependencies>

Com a programadors d’aplicacions orientades a objectes, el que us interessa és treballar amb objectes que representin les dades, més que haver de treballar directament amb SQL. JPA permet això, utilitza ORM (Object Relational Mapping) per emmagatzemar i recuperar dades de la base de dades a través de l’ús de classes de tipus entitat (entity classes). Mitjançant l’anotació @Entity es transforma una classe Java simple (POJO, Plain Old Java Object) en una EJB (Enterprise Java Bean). L’ús d’EJB permet gaudir dels serveis prestats pels servidors Java Enterprise Edition (Java EE). Hi ha diferents serveis que proporciona el seu ús, com clustering, transaccionalitat a través JTA, seguretat i connexions amb base de dades. A més de l’anotació @Entity hi ha altres anotacions que permeten definir quins atributs de la classe seran persistents i a quina columna de la taula seran emmagatzemats. En el següent codi podeu veure les diferents anotacions que farem servir.

  @Entity
  @Table(name = "users")
  public class User implements Serializable{
    private static final long serialVersionUID = 1L;
    @Id
    @NotNull
    @Column(name = "user_id")
    private Long userId;
 
    @NotNull
    @Size(max = 30)
    @Column(name = "username")
    private String username;
 
    @NotNull
    @Size(max = 30)
    @Column(name = "name")
    private String name;
 
    @NotNull
    @Size(max = 30)
    @Column(name = "email")
    private String email;
 
    @NotNull
    @Size(max = 30, min = 5)
    @Column(name = "password")
    private String password;
 
    @NotNull
    @Column(name = "rank")
    private Integer rank;
 
    @NotNull
    @Column(name = "active")
    private Boolean active;
 
    @NotNull
    @Column(name = "created_on")
    private Timestamp createdOn;
 
    public User(){}
 
    public Long getUserId() {
        return userId;
    }
 
    public void setUserId(Long userId) {
        this.userId = userId;
    }
 
    public String getUsername() {
        return username;
    }
 
    public void setUsername(String username) {
        this.username = username;
    }
 
    public String getName() {
        return name;
    }
 
    public void setName(String name) {
        this.name = name;
    }
 
    public String getEmail() {
        return email;
    }
 
    public void setEmail(String email) {
        this.email = email;
    }
 
    public String getPassword() {
        return password;
    }
 
    public void setPassword(String password) {
        this.password = password;
    }
 
    public Integer getRank() {
        return rank;
    }
 
    public void setRank(Integer rank) {
        this.rank = rank;
    }
 
    public Boolean getActive() {
        return active;
    }
 
    public void setActive(Boolean active) {
        this.active = active;
    }
 
    public Timestamp getCreatedOn() {
        return createdOn;
    }
 
    public void setCreatedOn(Timestamp createdOn) {
        this.createdOn = createdOn;
    }
}

L’anotació @Entity indica que serà una classe de tipus entitat i l’anotació @Table permet indicar quin és el nom de la taula que estarà lligada a aquesta classe. Un altre aspecte que és important destacar és que és sempre una bona idea fer que una classe de tipus entitat sigui serialitzable, per tal que la classe pugui ser passada per valor i no per referència. Això s’aconsegueix fent que la classe implementi la interfície java.io.Serializable i afegint l’atribut estàtic serialVersionUID. Sense entrar en molts detalls, serialVersionUID s’utilitza per comprovar que els objectes serialitzats i desserialitzats són compatibles.

Una classe del tipus entitat necessita tenir un constructor sense arguments i atributs per a cada una de les columnes de la taula. Les anotacions JPA que hem utilitzat les podeu veure en la taula.

Hi ha altres anotacions que hem utilitzat i que no apareixen en la llista. Intenteu contestar a les següents preguntes abans de continuar:

• Quines són les anotacions que hem utilitzat i que no pertanyen a l’API de JPA?
• A quina API pertanyen?
• Per a què creieu que serveixen?

Les anotacions que no són part de JPA i que hem utilitzat (taula) són part de l’API javax.validation i serveixen per validar les dades que guardarem a la base de dades abans d’intentar guardar-les.

Com ja hem vist, JPA és una especificació que indica com es transformen classes en entitats i com aquestes es poden fer servir per llegir i escriure en una base de dades. És una especificació però no una implementació, és a dir, defineix com han de ser les operacions però no les implementa. Això vol dir que amb l’exemple de la classe User que hem vist no podem fer cap operació amb la base de dades. Per poder fer-ho hi ha dues opcions: utilitzar Persistence Units (unitats de persistència) o emprar Enterprise Java Beans, que requerirà de l’ús d’un servidor d’aplicacions com pot ser Glassfish.

Les unitats de persistència són les peces que enllacen l’entitat que hem definit amb la base de dades. Poden usar un pool de connexions amb la BD definides al servidor d’aplicacions o, com en l’exemple següent, una connexió JDBC. El que es aconseguir és crear una unitat de persistència que pugueu utilitzar en els tests unitaris. Obriu el codi que crearà el projecte UDF4-02. Al fitxer src/test/resources/META-INF/persistence.xml trobareu la configuració de la unitat de persistència.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="InMemoryH2PersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <class>org.ioc.daw.user.User</class>
        <properties>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="username"/>
            <property name="javax.persistence.jdbc.password" value="password"/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:mem:socioc_db"/>
        </properties>
    </persistence-unit>
</persistence>

El fitxer XML que defineix la unitat de persistència és on resideix informació que necessita JPA per saber com connectar-se a la BD. Aquest fitxer pot contenir la configuració de com connectar-se a múltiples BD. Cadascuna d’aquestes configuracions indicarà el tipus de transacció que s’utilitzarà a l’hora de fer les operacions amb la BD que serà JTA o RESOURCE_LOCAL.

A persistence-unit name= s’indica el nom de la unitat de persistència, que serà utilitzat a l’aplicació per obtenir una referència a la configuració que defineix com ens connectem a la BD. El tipus de transacció indica si s’utilitzarà Java Transaction API (JTA) entity managers (gestors d’entitats) per ser utilitzats en un servidor d’aplicacions o bé entity managers locals que no necessiten de cap servidor d’aplicacions, i que és el tipus que us interessa per als vostres tests unitaris.

<class> permet definir quines classes (en el vostre cas només n’hi ha una, de moment) seran mapejades amb la BD. Després es defineixen els elements que permeten la connexió amb la BD. En aquest cas, nom d’usuari i contrasenya per accedir a la BD i l’string de connexió que defineix com accedir a la base de dades.

Un cop heu establert com es farà la connexió amb la base de dades, ja podeu escriure un test unitari.

  public class UserTest {
    private EntityManager entityManager;
    private EntityTransaction entityTransaction;
 
    @Before
    public void setUp() {
        entityManager  = Persistence.createEntityManagerFactory("InMemoryH2PersistenceUnit").createEntityManager();
        entityTransaction = entityManager.getTransaction();
    }
 
    @After
    public void cleanUp() {
        entityManager.close();
    }
 
    @Test
    public void findAllUsers(){
 
        User user = new User();
        user.setActive(true);
        user.setCreatedOn(new Timestamp(new Date().getTime()));
        user.setEmail("test@test.com");
        user.setName("Jane");
        user.setPassword("password");
        user.setRank(100);
        user.setUsername("jdoe");
        user.setUserId(23L);
 
        entityTransaction.begin();
        entityManager.persist(user);
        entityTransaction.commit();
 
        Query query = entityManager.createNativeQuery("select * from users", User.class);
        List<User> userList = query.getResultList();
        Assert.assertEquals(1, userList.size());
        Assert.assertEquals("jdoe", userList.get(0).getUsername());
    }
 
}

Amb Persistence.createEntityManagerFactory definiu quina serà la unitat de persistència que necessitareu per crear l‘EntityManager. Després creeu un objecte per fer transaccions amb la BD; és part del mètode setUp, perquè aquest objecte l’utilitzareu en tots els tests. Al test findAllUsers primer creeu un objecte User (que, recordeu, serà una entitat), inicieu la transacció amb la BD, salveu l’objecte amb entityManager.persist(user); i finalment dieu a l’objecte que gestiona les transaccions que apliqui tots els canvis a la BD. Fixeu-vos que no serà fins a entityTransaction.commit() que els canvis s’escriuran a la base de dades. Finalment, el test comprova que a la taula “Users” de la BD només hi ha una entrada i que correspon a l’usuari que acabeu de crear. Executeu el test i obtindreu el següent error:

javax.persistence.PersistenceException: No resource files named META-INF/services/javax.persistence.spi.PersistenceProvider were found. Please make sure that the persistence provider jar file is in your classpath.

  at javax.persistence.Persistence.findAllProviders(Persistence.java:167)

Quin és el motiu pel qual teniu aquest error?

Com ja heu vist, JPA només és una especificació, però no una implementació. L’error vol dir exactament això: quan s’intenta executar el codi no es troba cap llibreria (PersistenceProvider) que implementi JPA, per la qual cosa resulta impossible fer cap operació amb la base de dades. Ho solucionareu utilitzant la implementació EclipseLink. No entrarem en detalls sobre EclipseLink, ja que més endavant utilitzareu Hibernate com a implementació.

Per incloure EclipseLink al nostre projecte, el primer serà modificar el fitxer de dependències pom.xml.

  <dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>2.5.0</version>
  </dependency>

A continuació haureu de modificar la unitat de persitència per indicar quina implementació utilitzareu:

    <persistence-unit name="InMemoryH2PersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <class>org.ioc.daw.user.User</class>
        <properties>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="username"/>
            <property name="javax.persistence.jdbc.password" value="password"/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:mem:socioc_db;INIT=runscript from 'classpath:init.sql'"/>
            <property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/>
            <property name="javax.persistence.schema-generation.create-source" value="metadata"/>
            <property name="javax.persistence.schema-generation.drop-source" value="metadata"/>
        </properties>
    </persistence-unit>

A la línia 2 s’ha afegit quina serà la implementació del PersistenceProvider. A la línia 8, on s’indica l’string de connexió, afegim també que s’executi un script on creareu la taula “Users”, que utilitzareu per emmagatzemar els usuaris del nostre sistema. El fitxer src/test/resources/init.sql té el següent contingut:

CREATE TABLE users(user_id INT PRIMARY KEY AUTO_INCREMENT NOT NULL,
                  username VARCHAR(30) NOT NULL,
                  name  VARCHAR(20) NOT NULL,
                  email VARCHAR(50) NOT NULL,
                  password VARCHAR(50) NOT NULL,
                  rank INT DEFAULT 0,
                  active BOOLEAN DEFAULT TRUE,
                  created_on TIMESTAMP AS CURRENT_TIME)

Torneu a executar el test findAllUsers, que aquest cop hauria de passar. Un problema d’aquest codi és que la lògica per emmagatzemar i recuperar usuaris està al test. És important que aquest codi estigui a la seva pròpia classe per tal que es pugui utilitzar en tota l’aplicació. Creareu una classe, UserService, que s’encarregarà d’aquesta funció i que tindrà la lògica necessària per guardar un usuari a la base de dades, modificar-lo i buscar usuaris pel seu nom. Començareu creant una interfície que definirà les operacions relacionades amb la BD. Programar utilitzant interfícies té avantatges, com heu pogut veure amb JPA. Es defineix una interfície i després es pot canviar la implementació; així, si canviéssiu de BD i per exemple escollíssiu una BD NoSQL on no es pugui utilitzar JPA només hauríeu de preocupar-vos de canviar la implementació. Definiu la interfície org.ioc.daw.user.UserDAO que us permeti guardar usuaris a la BD, esborrar-los, modificar-los i trobar un usuari pel seu nom.

  public interface UserService {
    public void create(User user);
    public void edit(User user);
    public void remove(User user);
    public User findUserByUsername(String username);
  }

A continuació creeu la seva implementació:

public class UserServiceImpl implements UserService {
    private EntityManager entityManager;
 
    public UserServiceImpl(EntityManager entityManager) {
        this.entityManager = entityManager;
    }
 
    @Override
    public void create(User user) {
        entityManager.persist(user);
    }
 
    @Override
    public void edit(User user) {
        entityManager.merge(user);
    }
 
    @Override
    public void remove(User user) {
        entityManager.remove(user);
    }
 
    @Override
    public User findUserByUsername(String username) {
      return (User) entityManager.createQuery("select object(o) from User o " +
          "where o.username = :username")
          .setParameter("username", username)
          .getSingleResult();
    }
}

Els mètodes create, remove i edit defineixen les operacions JPA per guardar, actualitzar i esborrar entitats de la BD. La part més interessant és la del mètode findUserByUsername. Utilitzeu createQuery, i en aquest cas feu servir una consulta parametritzada on indiqueu la classe de l’objecte que retornarà la consulta, el paràmetre que passareu (username) i que només retornarà un resultat, ja que només podeu tenir un usuari amb un nom determinat. El test el podeu implementar de la següent manera (en aquest cas emmagatzemeu dos usuaris):

public class UserServiceTest {
    private EntityManager entityManager;
    private EntityTransaction entityTransaction;
    private UserService userService;
 
    @Before
    public void setUp() {
        entityManager  = Persistence.createEntityManagerFactory("InMemoryH2PersistenceUnit").createEntityManager();
        userService = new UserServiceImpl(entityManager);
        entityTransaction = entityManager.getTransaction();
    }
 
    @After
    public void cleanUp() {
        entityManager.close();
    }
 
    @Test
    public void findAllUsers(){
        String username = "jdoe";
        User user = new User();
        user.setActive(true);
        user.setCreatedOn(new Timestamp(new Date().getTime()));
        user.setEmail("test@test.com");
        user.setName("Jane");
        user.setPassword("password");
        user.setRank(100);
        user.setUsername(username);
        User user1 = new User();
        user1.setActive(true);
        user1.setCreatedOn(new Timestamp(new Date().getTime()));
        user1.setEmail("test1@test.com");
        user1.setName("Joe");
        user1.setPassword("password");
        user1.setRank(100);
        user1.setUsername("joeTest");
 
        entityTransaction.begin();
        userService.create(user);
        userService.create(user1);
        entityTransaction.commit();
 
        User userFromDB = userService.findUserByUsername(username);
        Assert.assertNotNull(userFromDB);
        Assert.assertEquals("jdoe", userFromDB.getUsername());
        Assert.assertEquals("test@test.com", userFromDB.getEmail());
        Assert.assertNotNull(userFromDB.getUserId());
    }
}

Fixeu-vos que en aquest test no heu donat valor a userId, però tal com testeja Assert.assertNotNull(userFromDB.getUserId()); sí que té un valor. Quina anotació JPA s’ha d’afegir a l’atribut userId de la classe User que generarà automàticament un valor? La resposta és GeneratedValue.

  @Id
  @NotNull
  @GeneratedValue
  @Column(name = "user_id")
  private Long userId;

Quan vulgueu desplegar la vostra aplicació, utilitzar EclipseJPA com a implementació de JPA no serà suficient. Necessiteu un servidor d’aplicacions que permeti desplegar aplicacions Java EE. Glassfish és el servidor d’aplicacions de referència per a aplicacions Java EE i inclou les tecnologies EJB, JPA, JSF (Java Server Faces) i JMS (Java Messaging System). Netbeans inclou per defecte un servidor Glassfish. A la pestanya Serveis, tal com podeu veure en la figura, ja hi ha un servidor Glassfish configurat.

Arranqueu el servidor; després d’uns segons estarà funcionant, i si feu clic a Resources veureu que hi ha dues carpetes, JDBC Resources i Connection Pools (vegeu la figura).

Un pool de connexions és un sèrie de connexions amb la BD que es guarden en cache i que poden ser reutilitzades per diferents consultes que es facin a la BD. El motiu d’utilitzar-les és que milloren notablement el rendiment de l’aplicació i la fan molt més ràpida. La gestió d’obrir i tancar connexions amb al BD cada cop que es necessiti guardar o recuperar dades és molt costosa, especialment en aplicacions dinàmiques on el contingut es genera dinàmicament a partir de les dades de la BD. La forma de funcionar és que quan es crea una connexió es posa al pool, de manera que quan es torni a necessitar la connexió no s’ha de tornar a establir. El que volem fer és establir un pool de connexions amb la base de dades MySQL. Per fer-ho, un cop el servidor Glassfish ha arrencat, accediu a la consola d’administració (vegeu la figura).

La consola d’administració és una aplicació web, així que s’obrirà una finestra al vostre navegador. Navegueu a Resources/JDBC/JDBC Connection Pools i veureu els pools de connexions creats per defecte (vegeu la figura).

Feu clic a New i podreu crear el pool de connexions. Es fa en dues parts. En la primera part es dóna nom al pool de connexions i se selecciona el tipus de recurs i el driver que s’utilitzarà per connectar-se amb la base de dades (vegeu la figura).

A continuació es configuren els paràmetres del pool de connexions (vegeu la figura). Els que hi ha per defecte ja aniran bé, així que no els canviareu. Cal destacar els següents:

• Initial and Minimum Pool Size: nombre mínim de connexions amb la BD que mantindrem al pool.
• Maximum Pool Size: nombre màxim de connexions simultànies que mantindrem al pool.
• Pool Resize Quantity: nombre de connexions que es trauran del pool quan no hi hagi activitat durant més del temps establert pel paràmetre Idle Timeout.
• Idle Timeout: temps màxim que una connexió pot estar inactiva.

Els únics valors que heu de canviar són els relatius al nom de la base de dades, l’usuari, la contrasenya, la IP i el port que utilitza el servidor MySQL, que trobareu al final de la pàgina web (vegeu la figura).

Un cop configurat, assegureu-vos que la connexió amb la BD funciona utilitzant el botó Ping. Si obteniu l’error mostrat en la figura és perquè el servidor Glassfish no pot accedir al driver de connexió amb MySQL.

En aquest cas feu el següent:

1. Descarregueu-vos el connector de dev.mysql.com/downloads/connector/ j/5.1.html.
2. Descomprimiu-lo i copieu l’arxiu mysql-connector-java-5.1.40-bin.jar a /instalacio-del-servidor-glassfish/glassfish-4.1/glassfish/domains/domain1 /lib/ . Glassfish estarà instal·lat en el directori on hagueu instal·lat Netbeans. Per veure on està instal·lat exactament mireu les propietats del servidor Glassfish (Installation Location) (vegeu la figura i la figura).

Un recurs JDBC proporciona a una aplicació la forma de connectar-se a una base de dades. Típicament, l’administrador del servidor Glassfish crearà un recurs JDBC que establirà quin dels pools de connexions utilitzarà l’aplicació. Cada recurs JDBC creat al servidor d’aplicacions tindrà un únic identificador JNDI (Java Naming and Directory Interface). JNDI és un servei ofert pels servidors d’aplicacions Java EE que permet als clients (en aquest cas, l’aplicació que estem desenvolupant) descobrir serveis i objectes utilitzant un nom. L’objecte que la vostra aplicació descobrirà serà l’objecte que representa el pool de connexions. A l’hora d’escollir el nom per al recurs JDBC es pot triar qualsevol, però per convenció s’utilitza jdbc/nom_del_recurs_pm. Per crear un recurs JDBC aneu a la consola d’administració de Glassfish i navegueu a Resources/JDBC/JDBC Resources. Amb el botó New, creeu un nou recurs i afegiu-hi les dades, tal com podeu veure en la figura.

Si refresqueu la informació del servidor Glassfish a Netbeans hauríeu de veure tant el recurs JDBC creat com el pool de connexions (vegeu la figura).

Un cop ja teniu el pool de connexions i el recurs JDBC creat, ja podeu fer que la vostra aplicació els utilitzi. Per fer-ho haureu de definir una unitat de persistència que especifiqui el recurs JDBC que utilitzareu. A partir del codi , importeu el projecte UDF4-02 i editeu el fitxer persistence.xml i amb el següent contingut:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="InMemoryH2PersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <class>org.ioc.daw.user.User</class>
        <properties>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="username"/>
            <property name="javax.persistence.jdbc.password" value="password"/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:mem:socioc_db;INIT=runscript from 'classpath:init.sql'"/>
            <property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/>
            <property name="javax.persistence.schema-generation.create-source" value="metadata"/>
            <property name="javax.persistence.schema-generation.drop-source" value="metadata"/>
        </properties>
    </persistence-unit>
    <persistence-unit name="MysqlResourceSocIocPersistence" transaction-type="JTA">
        <jta-data-source>jdbc/socioc__pm</jta-data-source>
        <class>org.ioc.daw.user.User</class>
        <properties>
            <property name="eclipselink.logging.level" value="FINEST"/>
        </properties>
    </persistence-unit>
</persistence>

Hi ha diversos canvis. El primer és que la definició de la nova unitat de persistència MysqlResourceSocIocPersistence és molt més simple. Penseu que ara tots els detalls de la connexió estan gestionats per Glassfish, així que vosaltres només us heu de preocupar d’indicar quin serà el recurs JDBC que utilitzareu. L’única propietat que s’ha afegit a la línia 23 és eclipselink.logging.level, que indica el nivell de logging de l’aplicació i que serà útil per solucionar problemes. Al test unitari anterior, la gestió de les transaccions era part del test.

    entityTransaction.begin();
    userService.create(user);
    userService.create(user1);
    entityTransaction.commit();

Això no hauria de formar part del test, ja que el que us interessa és que sigui la classe que fa les consultes a la BD la que s’encarregui de gestionar les transaccions. A més a més, en utilitzar un servidor d’aplicacions les vostres classes seran ara entitats de ple dret, per la qual cosa es pot aprofitar per simplificar el codi utilitzant anotacions. Per fer-ho haureu d’afegir la següent dependència al fitxer pom.xml.

 <dependency>
      <groupId>javax.ejb</groupId>
      <artifactId>javax.ejb-api</artifactId>
      <version>3.2</version>
  </dependency>

Vegeu com s’ha de modificar la classe UserServiceImpl:

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class UserServiceImpl implements UserService {
    @PersistenceContext(unitName = "MysqlResourceSocIocPersistence")
    private EntityManager entityManager;
 
    @Resource
    private EJBContext context;
 
    @Override
    public void create(User user) {
        UserTransaction utx = context.getUserTransaction();
        try {
            utx.begin();
            entityManager.persist(user);
            utx.commit();
        } catch (Exception e) {
            e.printStackTrace();
            try {
                utx.rollback();
            } catch (Exception e1) {
                e1.printStackTrace();
            }
        }
    }
 
    @Override
    public void edit(User user) {
        UserTransaction utx = context.getUserTransaction();
        try {
            utx.begin();
            entityManager.merge(user);
            utx.commit();
        } catch (Exception e) {
            try {
                utx.rollback();
            } catch (Exception e1) {
                e1.printStackTrace();
            }
            e.printStackTrace();
        }
    }
 
    @Override
    public void remove(User user) {
        UserTransaction utx = context.getUserTransaction();
        try {
            utx.begin();
            entityManager.remove(user);
            utx.commit();
        } catch (Exception e) {
            try {
                utx.rollback();
            } catch (Exception e1) {
                e1.printStackTrace();
            }
            e.printStackTrace();
        }
    }
 
    @Override
    public User findUserByUsername(String username) {
      return (User) entityManager.createQuery("select object(o) from User o " +
        "where o.username = :username")
        .setParameter("username", username)
        .getSingleResult();
    }

L’anotació Stateless transforma un POJO en una EJB de sessió que adquireix la capacitat d’executar operacions en un servidor d’aplicacions (Glassfish, en el vostre cas). TransactionManagement és necessària per permetre fer operacions amb la BD a través del servidor d’aplicacions. En aquest cas, farà que hi hagi disponible al context de EJB (EJBContext) la classe UserTransaction, que utilitzareu per indicar quan comencen i acaben les transaccions amb la BD. L’anotació PersistenceContext permet declarar quina serà la unitat de persistència que utilitzareu per indicar com l’EJB UserServiceImpl s’ha de connectar amb la BD. Finalment, a cadascun dels mètodes que s’encarreguen de modificar dades a la BD utilitzeu UserTransaction per establir quan comencen i acaben les transaccions. Hi ha un mètode, utx.rollback(), que desfarà les dades modificades a la BD en cas que hi hagi un error.

A continuació cal modificar el vostre test unitari. Hi ha un problema: volem que el test utilitzi el recurs JDBC que heu creat al servidor Glassfish. Això vol dir que el vostre test ha de poder accedir a les EJB a Glassfish. Per aconseguir-ho utilitzareu un servidor Glassfish-embedded, que s’iniciarà durant els tests i permetrà accedir als recursos JDBC i EJB del servidor real Glassfish. El primer pas és afegir unes dependències al fitxer pom.xml. Fixeu-vos que heu de substituir DIRECTORI_INSTALACIO_NETBEANS pel directori on tingueu instal·lat el servidor Glassfish (vegeu la figura i la figura). També heu de copiar el fitxer mysql-connector-java-5.1.40-bin.jar al directori /NetBeans/glassfish-4.1/glassfish/lib/embedded.

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <glassfish.embedded-static-shell.jar>/DIRECTORI_INSTALACIO_NETBEANS/glassfish-4.1//glassfish/lib/embedded/glassfish-embedded-static-shell.jar</glassfish.embedded-static-shell.jar>
    <glassfish.mysql.jar>/DIRECTORI_INSTALACIO_NETBEANS/glassfish-4.1//glassfish/lib/embedded/mysql-connector-java-5.1.40-bin.jar</glassfish.mysql.jar>
</properties>
 
<dependencies>
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.4.190</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
    	<artifactId>junit</artifactId>
    	<version>4.12</version>
    </dependency>
    <dependency>
        <groupId>javax.validation</groupId>
        <artifactId>validation-api</artifactId>
        <version>1.1.0.Final</version>
    </dependency>
    <dependency>
        <groupId>org.eclipse.persistence</groupId>
        <artifactId>eclipselink</artifactId>
        <version>2.5.0</version>
    </dependency>
    <dependency>
        <groupId>org.glassfish.main.extras</groupId>
        <artifactId>glassfish-embedded-all</artifactId>
        <version>4.1.1</version>
        <scope>system</scope>
        <systemPath>${glassfish.embedded-static-shell.jar}</systemPath>
    </dependency>
    <dependency>
        <groupId>javax.ejb</groupId>
        <artifactId>javax.ejb-api</artifactId>
        <version>3.2</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.40</version>
        <scope>system</scope>
        <systemPath>${glassfish.mysql.jar}</systemPath>
    </dependency>
</dependencies>

A continuació creeu un test que utilitzarà el recurs JDBC definit a UserServiceImpl i que, per tant, escriurà dades a la BD MySQL que heu creat.

  @Before
  public void setUp() throws NamingException {
      Context context = EJBContainer.createEJBContainer().getContext();
      userService = (UserService) context.lookup("java:global/classes/UserServiceImpl");
  }
 
  @Test
  public void findUserByUsername() {
      String username = "jdoe";
      User user = new User();
      user.setActive(true);
      user.setCreatedOn(new Timestamp(new Date().getTime()));
      user.setEmail("test@test.com");
      user.setName("Jane");
      user.setPassword("password");
      user.setRank(100);
      user.setUsername(username);
      User user1 = new User();
      user1.setActive(true);
      user1.setCreatedOn(new Timestamp(new Date().getTime()));
      user1.setEmail("test1@test.com");
      user1.setName("Joe");
      user1.setPassword("password");
      user1.setRank(100);
      user1.setUsername("joeTest");
 
      userService.create(user);
      userService.create(user1);
 
      User userFromDB = userService.findUserByUsername(username);
      Assert.assertNotNull(userFromDB);
      Assert.assertEquals("jdoe", userFromDB.getUsername());
      Assert.assertEquals("test@test.com", userFromDB.getEmail());
      Assert.assertNotNull(userFromDB.getUserId());
  }

Primer inicialitzeu el servidor Glassfish-embedded i recupereu l’EJB del contenidor d’EJB del servidor Glassfish real. Un cop teniu l’EJB UserServiceImpl ja podeu fer les operacions amb la base de dades. Executeu el test, i hauríeu d’obtenir un error similar al de la figura.

Per què creieu que teniu aquest error?

• Perquè no es pot connectar amb la BD?
• Perquè la taula “Users” no està disponible?
• Perquè la taula “Sequence” no existeix?

L’error és perquè la taula “Sequence” no existeix, no l’heu definit i no hi feu referència enlloc; llavors, quan s’està intentant crear? Per què quan vau fer el test amb la BD en memòria no va fallar? La resposta està a la classe User.

  @GeneratedValue
  @Column(name = "user_id")
  private Long userId;

L’anotació GeneratedValue té com a estratègia per defecte GenerationType.AUTO, que intentarà crear la taula “Sequence” per guardar el valor autogenerat per al camp “user_id” de la taula. Com que la taula no existeix, l’aplicació acaba amb un error, ja que no hi pot escriure. A la vostra taula vau definir que el cap que formaria la clau principal s’autoincrementaria, llavors l’estratègia que heu d’utilitzar és GenerationType.IDENTITY. Modifiqueu la classe User.

  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name = "user_id")
  private Long userId;

Executeu el test un altre cop, aquesta vegada tindreu el següent error:

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'user_id' in 'field list'

L’error diu ara que no existeix un camp anomenat “user_id” a la taula “Users”. Netbeans deixa crear una connexió amb la BD que us permetrà examinar l’estructura de la taula. Seleccioneu la pestanya “Services”, feu clic amb el botó dret a Database i registreu una connexió amb un servidor MySQL, tal com podeu veure en la figura.

A continuació, afegiu les dades del vostre servidor MySQL (vegeu la figura).

Un cop definida la connexió ja podeu examinar el contingut de la taula “Users” (vegeu la figura) a través de la pestanya “Services” de Netbeans.

El problema és que la columna de la taula “Users” s’anomena “id” i no “user_id”. Canvieu, doncs, la classe User.

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name = "id")
  private Long userId;

Executeu de nou el test, i ara acabarà sense cap error. Com que heu utilitzat la BD MySQL, podeu veure que els dos usuaris creats al tests estan a la taula “Users”. Amb l’opció Execute command (vegeu la figura) podeu executar consultes i veure que la taula conté els registres esperats (vegeu la figura).

Escriure test unitaris que modifiquin el contingut de la base de dades MySQL és un problema. Penseu que aquesta serà la BD que utilitzareu per a la vostra aplicació; tenir un test que escriu dades a aquesta BD és, doncs, un error. Us ha servit per veure com utilitzar el servidor Glassfish per emprar un recurs JDBC i escriure a la BD, però ho heu de canviar.

Un altre problema està a la classe UserServiceImpl. El primer problema és que esteu determinant quina unitat de persistència utilitzarà aquesta EJB, i això impossibilita escollir quina unitat de persistència emprar quan s’executen els tests. Heu de refactoritzar el codi per tal de poder escollir la unitat de persistència en funció que executeu tests unitaris o desplegueu l’aplicació al servidor Glassfish.

@PersistenceContext(unitName = “MysqlResourceSocIocPersistence")

Un altra cosa que podeu millorar es la gestió de les transaccions. Aquest és el codi que heu utilitzat:

@Override
 public void create(User user) {
     UserTransaction utx = context.getUserTransaction();
     try {
         utx.begin();
         entityManager.persist(user);
         utx.commit();
     } catch (Exception e) {
         e.printStackTrace();
         try {
             utx.rollback();
         } catch (Exception e1) {
             e1.printStackTrace();
         }
     }
 }

El que passa és que quan s’utilitza l’anotació @Stateless, automàticament EJB proporciona la següent anotació a cadascun dels mètodes @TransactionAttribute(TransactionAttributeType.REQUIRED). Això fa que s’encarregui automàticament de gestionar les transaccions; per tant, podeu simplificar la classe UserServiceImpl notablement.

@Stateless
public class UserServiceImpl implements UserService {
    @PersistenceContext
    private EntityManager entityManager;
 
    @Override
    public void create(User user) {
        entityManager.persist(user);
    }
 
    @Override
    public void edit(User user) {
        entityManager.merge(user);
    }
 
    @Override
    public void remove(User user) {
        entityManager.remove(user);
    }
 
    @Override
    public User findUserByUsername(String username) {
      return (User) entityManager.createQuery("select object(o) from User o " +
        "where o.username = :username")
        .setParameter("username", username)
        .getSingleResult();
    }
}

De la forma que heu fet el test anterior era necessari que el servidor Glassfish estigués corrent. Això és un problema, ja que necessiteu executar els tests de manera independent del servidor d’aplicacions, i el més important: heu de ser capaços de poder especificar la unitat de persistència que voleu utilitzar en cada moment. Per poder aconseguir això fareu servir Arquillian (red.ht/2ls9x1Q), que és un framework de testeig que facilita escriure tests del components EJB. Utilitzant Arquillian podreu llançar una versió d’un servidor Glassfish en memòria que us permetrà accedir a les EJB tal com si estiguessin corrent al servidor real. Per aconseguir això, el primer que heu de fer és afegir unes dependències. Hi ha uns quants canvis, per la qual cosa aquí teniu tot el fitxer pom.xml.

 <dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-bom</artifactId>
            <version>1.1.11.Final</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
    </dependencies>
</dependencyManagement>
 
<dependencies>
    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <version>1.4.190</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
    </dependency>
    <dependency>
        <groupId>javax.validation</groupId>
        <artifactId>validation-api</artifactId>
        <version>1.1.0.Final</version>
    </dependency>
    <dependency>
        <groupId>org.eclipse.persistence</groupId>
        <artifactId>eclipselink</artifactId>
        <version>2.6.4</version>
    </dependency>
    <dependency>
        <groupId>javax.ejb</groupId>
        <artifactId>javax.ejb-api</artifactId>
        <version>3.2</version>
    </dependency>
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.40</version>
    </dependency>
 
    <dependency>
        <groupId>javax.el</groupId>
        <artifactId>javax.el-api</artifactId>
        <version>3.0.1-b04</version>
    </dependency>
 
    <dependency>
        <groupId>org.jboss.arquillian.container</groupId>
        <artifactId>arquillian-glassfish-embedded-3.1</artifactId>
        <version>1.0.0.Final</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.glassfish.main.extras</groupId>
        <artifactId>glassfish-embedded-all</artifactId>
        <version>4.1.1</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>javax.inject</groupId>
        <artifactId>javax.inject</artifactId>
        <version>1</version>
    </dependency>
 
    <dependency>
        <groupId>org.jboss.arquillian.junit</groupId>
        <artifactId>arquillian-junit-container</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

El primer que fareu serà separar el fitxer on definiu les unitats de persistència en dos fitxers. Un contindrà la unitat de persistència per escriure a la BD MySQL i l’altre la unitat de persistència per a testeig (vegeu la figura).

Aquest és la unitat de persistència per escriure a MySQL:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="SocIocPersistenceUnit" transaction-type="JTA">
        <jta-data-source>jdbc/socioc__pm</jta-data-source>
        <class>org.ioc.daw.user.User</class>
        <properties>
            <property name="eclipselink.logging.level" value="FINEST"/>
        </properties>
    </persistence-unit>
</persistence>

I aquest és la unitat de persistència que utilitzareu per al testeig:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
    <persistence-unit name="SocIocPersistenceUnit-TEST" transaction-type="JTA">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <class>org.ioc.daw.user.User</class>
        <properties>
            <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
            <property name="javax.persistence.jdbc.user" value="username"/>
            <property name="javax.persistence.jdbc.password" value="password"/>
            <property name="javax.persistence.jdbc.url" value="jdbc:h2:mem:socioc_db;INIT=runscript from 'classpath:init.sql'"/>
            <property name="javax.persistence.schema-generation.database.action" value="drop-and-create"/>
            <property name="javax.persistence.schema-generation.create-source" value="metadata"/>
            <property name="javax.persistence.schema-generation.drop-source" value="metadata"/>
        </properties>
    </persistence-unit>
</persistence>

Ara ja podeu reescriure el test unitari. Si teniu el servidor Glassfish en execució pareu-lo, o tindreu conflictes de port.

@RunWith(Arquillian.class)
public class UserServiceTest {
    @Inject
    private UserService userService;
 
    @Deployment(testable = true)
    public static JavaArchive createTestableDeployment() {
        final JavaArchive jar = ShrinkWrap.create(JavaArchive.class, "example.jar")
                .addClasses(UserService.class, UserServiceImpl.class)
                .addAsManifestResource("META-INF/persistence-test.xml", "persistence.xml")
                .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"));
        return jar;
    }
 
    @Test
    public void findUserByUsername() {
        String username = "jdoe";
        User user = new User();
        user.setActive(true);
        user.setCreatedOn(new Timestamp(new Date().getTime()));
        user.setEmail("test@test.com");
        user.setName("Jane");
        user.setPassword("password");
        user.setRank(100);
        user.setUsername(username);
        User user1 = new User();
        user1.setActive(true);
        user1.setCreatedOn(new Timestamp(new Date().getTime()));
        user1.setEmail("test1@test.com");
        user1.setName("Joe");
        user1.setPassword("password");
        user1.setRank(100);
        user1.setUsername("joeTest");
 
        userService.create(user);
        userService.create(user1);
 
        User userFromDB = userService.findUserByUsername(username);
        Assert.assertNotNull(userFromDB);
        Assert.assertEquals("jdoe", userFromDB.getUsername());
        Assert.assertEquals("test@test.com", userFromDB.getEmail());
        Assert.assertNotNull(userFromDB.getUserId());
    }
}

@RunWith(Arquillian.class) indica que executareu el test utilitzant Arquillian, i a continuació injecteu l’EJB UserService. Això és possible perquè Arquillian crea un servidor Glassfish en memòria amb un contenidor amb totes les EJB de la vostra aplicació, la qual cosa us permet afegir-les a una determinada classe quan sigui necessari. A createTestableDeployment és on es configura el servidor d’aplicacions utilitzant Arquillian. La part més important és on indiqueu quines classes són les EJB que voleu afegir al contenidor EJB del servidor i quin és el fitxer amb la definició de la unitat de persistència que voleu fer servir.

Heu après que utilitzant JDBC directament al codi té una sèrie d’inconvenients, ja que fa que us hagueu d’encarregar de programar operacions de baix nivell amb la base de dades, com establir i tancar les connexions, encarregar-se del mapatge de les dades de la BD amb els objectes del codi, etc.

Per solucionar aquests problemes heu vist JPA, que és una especificació que determina i fa estàndards les operacions amb la BD. És una especificació però no hi ha una implementació, així que per fer els exemples hem utilitzat EclipseLink, una de les implementacions disponibles. També heu vist que, encara que pugueu utilitzar implementacions de JPA per accedir directament a les bases de dades, utilitzar un servidor EJB com Glassfish proporciona diversos avantatges.

Pel que fa a JPA, permet establir un pool de connexions per fer més eficients les operacions i reutilitzar les connexions establertes amb la BD, que són operacions molt costoses. Finalment, heu vist diferents formes de testejar aplicacions que treballen amb bases de dades i heu creat una estructura, separant les unitats de persistència i utilitzant el framework Arquillian, que pot servir de base per testejar qualsevol aplicació que treballi amb JPA.