1. Los módulos Spring Módulo

Hasta la fecha, la documentación de Spring lista unos veinte módulos Spring agrupados por temas. Para los ejemplos de este libro, se utilizan las versiones 4.3 y 5.3.

El núcleo central en las versiones 4.3.30 y 5.3.18

La POA

Mensajes

Acceso a los datos

Web

Prueba

2. Temas tratados

Como vimos en el prólogo, Spring es muy extenso. No podemos cubrir todo en un libro, aunque vamos a tratar los temas más utilizados, a saber, la parte back de las aplicaciones web y, a menudo, móviles, así como la parte front, para la que nos vamos a limitar a las aplicaciones web, ya que incluiremos los servicios web en esta parte. Describiremos tanto como sea posible las pruebas unitarias asociadas. Los ejemplos están tomados de casos reales presentes en los proyectos que se pueden descargar. También se detalla la programación por aspectos, que se utiliza ampliamente con Spring.

Los ejemplos utilizan la última versión «release» de Spring, disponible en el momento de escribir este libro, es decir, la versión 4.3.30 y la versión 5.3.18. Se basan en el uso de Java 17 y están en UTF-8. Los ejemplos están mavenizados para facilitar el manejo. Los componentes de Jakarta EE se corresponden con los de Jakarta EE 8, es decir, JSF2, JPA2, Servlet 3 (y 4), etc.

3. Versión de los componentes de Spring utilizados en el libro

Extracto de las versiones utilizadas

4. Versión de recursos externos

Lista de elementos externos clave

5. Gestión de dependencias de Maven Maven:dependencias

Los ejemplos utilizan el mecanismo clásico para las dependencias.

Solo utilizamos versiones de la última release (versión identificada como estable): 

<dependency> 
        <groupId>org.springframework</groupId> 
        <artifactId>spring-core</artifactId> 
        <version>4.3.30.RELEASE</version> 
      </dependency> 

o

<dependency> 
        <groupId>org.springframework</groupId> 
        <artifactId>spring-core</artifactId> 
        <version>5.3.18.RELEASE</version> 
      </dependency> 

El ejemplo de este capítulo muestra una configuración con todos los módulos y otras versiones comentadas.

Para la versión estándar, no podemos especificar un repositorio porque se trata de una versión generalizada en repositorios estándares Maven, pero también podemos especificar de manera precisa que deseamos que la versión se aloje en repositorios de Spring:

<repositories> 
          <repository> 
              <id>io.spring.repo.maven.release</id> 
              <url>http://repo.spring.io/release/</url> 
              <snapshots><enabled>false</enabled></snapshots> 
          </repository> 
      </repositories> 

Durante las fases de vigilancia tecnológica, puede ser necesario utilizar versiones que aún no están disponibles en los repositorios estándares.

Para la versión milestone:

<repositories> 
          <repository> 
              <id>io.spring.repo.maven.milestone</id> 
              <url>http://repo.spring.io/milestone/</url> 
              <snapshots><enabled>false</enabled></snapshots> 
          </repository> 
      </repositories> 

Y para las snapshot:

<repositories> 
          <repository> 
              <id>io.spring.repo.maven.snapshot</id> 
              <url>http://repo.spring.io/snapshot/</url> 
              <snapshots><enabled>true</enabled></snapshots> 
          </repository> 
      </repositories> 

6. Usar una BOM (Bill Of Materials) Maven Maven:BOM BOM

Una BOM Maven se remonta a la versión 2.0.9 de Maven y utiliza la noción de scope import.

Usamos los scopes Maven para actuar sobre el scope de nuestras dependencias.

El scope test permite, por ejemplo, importar las dependencias de los módulos utilizados por las pruebas solo durante la fase de test.

El scope import, que se utiliza en la sección dependencyManagement con una dependencia de tipo pom.xml, permite importar dependencias desde otro POM.

Por ejemplo:

Para el POM del proyecto1:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
      http://maven.apache.org/xsd/maven-4.0.0.xsd"> 

<modelVersion>4.0.0</modelVersion> 
        <groupId>fr.ediciones-eni</groupId> 
        <artifactId>pomA</artifactId> 
        <version>1</version> 
        <packaging>pom</packaging> 
       
         <dependencyManagement> 
          <dependencies> 
            <dependency> 
              <groupId>org.springframework</groupId> 
              <artifactId>spring-core</artifactId> 
              <version>4.3.30.RELEASE</version> 
             </dependency> 
          </dependencies> 
        </dependencyManagement> 
      </project> 

y para el POM del proyecto:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
      http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
      <modelVersion>4.0.0</modelVersion> 
        <groupId>fr.ediciones-eni</groupId> 
        <artifactId>pomB</artifactId> 
        <version>1</version> 
        <packaging>jar</packaging> 
       
        <dependencyManagement> 
          <dependencies> 
            <dependency> 
              <groupId>fr.ediciones-eni</groupId> 
              <artifactId>pomA</artifactId> 
              <version>1</version> 
              <scope>import</scope> 
              <type>pom</type> 
            </dependency> 
          </dependencies> 
        </dependencyManagement> 
      </project> 

Maven creará un POM compuesto como este:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
      http://maven.apache.org/xsd/maven-4.0.0.xsd"> 

<modelVersion>4.0.0</modelVersion> 
        <groupId>fr.ediciones-eni</groupId> 
        <artifactId>pomB</artifactId> 
        <version>1</version> 
        <packaging>jar</packaging> 
       
        <dependencyManagement> 
          <dependencies> 
            <dependency> 
              <groupId>org.springframework</groupId> 
              <artifactId>spring-core</artifactId> 
              <version>4.3.28.RELEASE</version> 
            </dependency> 
          </dependencies> 
         </dependencyManagement> 
      </project> 

BOM utiliza esta capacidad.

Una BOM es un POM BOM, que solo contiene una sección dependencyManagement.

Por ejemplo:

<dependency> 
         <groupId>org.springframework</groupId> 
         <artifactId>spring-core</artifactId> 
      </dependency> 

da:

<dependency> 
         <groupId>org.springframework</groupId> 
         <artifactId>spring-core</artifactId> 
         <version>4.3.30.RELEASE</version> 
      </dependency> 

Con esto se supera la limitación de Maven de disponer de un único POM padre.

La BOM garantiza que todas las dependencias directas y transitivas utilicen las mismas versiones.

La BOM utiliza los POM anidados y permite importar información desde otro POM. Definimos en la BOM todas las versiones de las dependencias que queremos utilizar en nuestros proyectos.

Los POM ya no contienen versiones para dependencias porque reutilizan la versión de la BOM.

<dependency> 
          <groupId>org.springframework</groupId> 
          <artifactId>spring-framework-bom</artifactId> 
          <version>${spring.version}</version> 
          <type>pom</type> 
          <scope>import</scope> 
      </dependency> 

Una ventaja adicional de utilizar la BOM es que ya no se puede usar el atributo <version>.

<dependencies> 
          <dependency> 
              <groupId>org.springframework</groupId> 
              <artifactId>spring-context</artifactId> 
          </dependency> 
          <dependency> 
              <groupId>org.springframework</groupId> 
              <artifactId>spring-web</artifactId> 
          </dependency> 
      <dependencies> 

En este libro, no utilizamos las BOM, para simplificar tanto como sea posible los archivos de configuración pom.xml.

Las empresas utilizan masivamente las BOM para actualizar todas las dependencias a la vez, pero en ocasiones esto dificulta la legibilidad. Existe un comando maven para listar todas las dependencias maven de un proyecto:

$ mvn dependency:tree 

Un capítulo dedicado explicará los conceptos básicos del uso de proyectos mavenizados, para permitir que las personas que aún no están familiarizadas con este modo de funcionamiento aprovechen al máximo los ejemplos.

1. Objetivo

Históricamente, cuando necesitábamos una acción, la implementábamos en el objeto que la requería. Por lo tanto, para un procesamiento idéntico había una multitud de copias de estas acciones en las diversas instanciaciones de los objetos que lo utilizaban. Esto se debía a que, en un sistema orientado a objetos, los procesos se encapsulan en objetos junto con los datos.

Para las acciones que no se basan en el estado del objeto que lo tiene, se decidió cambiar la acción a la parte estática de la clase. De hecho, la parte estática se comparte entre todas las instancias de la clase. Por lo tanto, no hay más duplicación de código en la memoria.

Algunos servicios se separan de los datos que procesan y, a continuación, se agrupan en clases no instanciadas como clases masivamente estáticas. Existe un sistema que, por un lado, separa los datos del procesamiento con los POJO, es decir, objetos sin procesamiento con excepción de los mecanismos de gestión de instancias (como constructores y descriptores de acceso) y, por otro lado, realiza el procesamiento separado de los datos como se haría en C. Con este tipo de arquitectura, alcanzamos rápidamente los límites del sistema.

En ese momento se desarrolla el singleton. Se trata de una clase que solo se instancia una vez y después todos la reutilizan. Soporta todos los conceptos de programación orientada a objetos. Por lo tanto, tenemos la simplicidad de uso de una clase, pero sin copias innecesarias.

Los primeros singletons (antes de que hubiera enumeraciones) usaban un código parecido al siguiente (en un sistema de un solo thread):

class MiSingleton 
           private static MiSingleton UNIQUE = null; 
           private MiSingleton(){ 
           } 
           public static synchronized MiSingleton getInstance() { 
         
              if (UNIQUE == null) { 
                 UNIQUE = new MiSingleton(); 
              } 
              return UNIQUE; 
           } 
        @Log 
        public class Main { 
           public static void main(String[] args) { 
              MiSingleton s1 = MiSingleton.getInstance(); 
              MiSingleton s2 = MiSingleton.getInstance(); 
         
              boolean test = s1==s2; 
              log.info("s1==s2:"+test); 
           } 

Hay una multitud de variaciones. Los más modernos usan una enumeración que, en esencia, es un singleton.

Es habitual encontrarnos con singletons en el código legacy. Cuando modificamos este código e implementamos pruebas unitarias con el framework Mockito, nos enfrentamos a las limitaciones de Mockito, que maneja mal las pruebas en partes estáticas y tenemos que usarlo junto con PowerMockito. A menudo se debe refactorizar y este refactoring en particular es costoso porque normalmente estos singletons se usan en muchos lugares del código. En sus nuevos desarrollos, ya no debe usar singletons puros y, en su lugar, debe aprovechar las funcionalidades adicionales que ofrece Singletons Spring.

2. Solución Spring

Spring permite crear Beans que sean singletons (una sola instancia) o prototipos (una instancia por bean). Cuando hablamos de una sola instancia, queremos decir que todos los objetos que tienen un bean singleton como miembro comparten este mismo objeto miembro en la memoria.

Veremos que es posible tener varios contextos Spring en una misma aplicación. Estos beans singleton definidos en la configuración Spring solo se crean una vez por contexto Spring. Por lo tanto, pueden ser múltiples en una aplicación que aloja varios contextos Spring.

Los Singletons Spring se parametrizan mediante configuración XML o anotaciones.

Cabe señalar que las anotaciones del JSR-330: Dependency Injection for Java (@Named, @Singleton) se pueden utilizar si en el classpath está presente la dependencia javax.inject. También es posible utilizar las anotaciones Spring @Bean, @Component, @Service, @Repository, etc., que especifican que usamos un singleton con peculiaridades inherentes a su función.

3. Ejemplo

En este ejemplo, se hace hincapié en que el singleton se comparte entre varios procesos, que se pueden ejecutar de manera concurrente (simultánea). Esto significa que, desde una perspectiva de memoria, puede haber dos secuencias de código que se ejecutan en paralelo en el mismo método. Uno de los procesamientos puede modificar un dato utilizado por el otro, lo que causará problemas muy rápidamente. Por lo tanto, es necesario proteger las áreas de riesgo, lo que comúnmente se llama «hacer el código Thread Safe» usando zonas sincronizadas para las que, en un momento t, solo se ejecuta un procesamiento en una porción de código, mientras que el resto de los procesos esperan su turno. Es posible proteger un proceso o variable con la palabra clave synchronized.

En general, evitaremos tener «estados» en los singletons, pero algunas veces los encontrará y deberá tener precaución. De hecho, hay efectos secundarios parasitarios en entornos multithreads.

Por ejemplo, un estado puede ser una variable de clase no estática que posteriormente se comparte por los métodos.

@Service 
        class ServicioUnico { 
           private int estado=0; 
         
           public synchronized int incEstado() { 
              //Operación larga 
              return ++estado; 
           } 
           public int getEstado() { 
              return estado; 
           } 
           public void setEstado(int estado) { 
              this.estado = estado; 
           } 
           void mostrarEstado() { 
              System.out.println(estado); 
           } 
           @Override 
           public int hashCode() { 
              final int primo = 31; 
              int resultado = 1; 
              resultado = primo * resultado + estado; 
              return resultado; 
           } 
           @Override 
           public String toString() { 
              return "ServicioUnico [estado=" + estado + "]"; 
           } 
           @Override 
           public boolean equals(Object obj) { 
              ServicioUnico other = (ServicioUnico) obj; 
              if (estado != other. estado) 
                 return false; 
              return true; 
           } 
        public class Main { 
           public static void main(String[] args) { 
                ApplicationContext context = 
        new ClassPathXmlApplicationContext("applicationContext.xml"); 
         
                ServicioUnico s1 = 
        ServicioUnico)context.getBean("servicioUnico"); 
                ServicioUnico s2 = 
        (ServicioUnico)context.getBean("servicioUnico"); 
              s1.setEstado(3); 
         
                System.out.println("Mismos valores (equals) ?: " 
        " + s1.equals(s2)); 
                System.out.println("Misma referencia (==)    ?: " 
        " + (s1==s2)); 
                System.out.println(s1); 
                System.out.println(s2); 
         
              s1.setEstado(2); 
              s2.mostrarEstado(); 
         { 
           } 

Mensajes en la consola:

¿Mismos valores (equals)?: true

Misma referencia (==) ?: true

ServicioUnico [estado=3]

ServicioUnico [estado=3]

Como veremos más adelante, Spring también permite hacer singletons en relación con un contexto de uso, utilizando scopes (ámbitos).

Por ejemplo, dado un bean de scope «session», para un usuario será único dentro de una sesión. Pero habrá tantos objetos como sesiones.

Hay otros scopes y también es posible crear sus propios scopes.

Por lo tanto, el objeto se convierte en único en su scope.

Por ejemplo, para un Bean Spring Singleton:

@Bean 
        @Scope("singleton") 
         public Person personSingleton() { 
         return new Person(); 
        } 

1. Descripción del problema

De forma predeterminada, Java se basa en identificadores de memoria para realizar operaciones equals y hashCode. Funciona bien para casos sencillos. Sin embargo, la codificación de equals y hashcode es problemática, especialmente en entornos basados en proxy, como Spring, Hibernate y JPA.

De hecho, la columna o columnas que llevan las claves primarias y que se mapean en el objeto en la variable o variables que llevan la anotación @Id o composite (@IdClass o @EmbeddedId) se rellenan solo después de guardar en la base de datos, para columnas para las que el id no está prefijado.

Todos los sistemas basados en colecciones utilizan los métodos equals y hashcode para determinar si el elemento existe en la colección.

Tenga en cuenta que el proxy Spring en los objetos sobrecarga estos métodos. De hecho, estos métodos se deben transferir al objeto representado por el proxy, pero no se pueden interceptar a través del AOP de Spring porque ya es un objeto proxy. No puede colocar un proxy en un proxy existente.

Si el objetivo es interceptar estos métodos, será necesario utilizar AspectJ de forma nativa.

Para los proxys relacionados con lazy loading (carga diferida o bajo demanda), se debe evitar comparar las referencias y los tipos de los objetos y centrarse en el contenido, lo que fuerza la carga en el caso de JPA e Hibernate o la instanciación e inyección del objeto en Spring.

2. Implementación

La solución más razonable es utilizar una clave de negocio basada en datos reales, pero esto es bastante difícil de mantener. A menudo, utilizamos una clave primaria secuencial independiente de las claves de negocio, que se distinguen mejor por su unicidad. Para la comparación, comparamos los valores, y para el hashcode, calculamos el hashcode de las variables y combinamos estos valores para obtener un hashcode global. Las cosas se complican si hacemos que intervengan los objetos vinculados en la comparación. Esta preocupación por la comparación y el hashcode normalmente se encuentra en una parte muy genérica y repetitiva del código, con bajo valor añadido, como es la capa domaine.

En los foros (https://discourse.hibernate.org/) se ha propuesto una solución.

import java.io.Serializable; 
        import java.rmi.dgc.VMID; 
        //tomado de aquí: https://forum.hibernate.org/viewtopic.php? 
        f=1&t=928172&start=105 
        public class ModelElabore implements Serializable { 
         
            private volatile VMID vmid; 
            private Long id; 
         
            public Long getId() { 
                return id; 
            } 
            private void setId(Long id) { 
                this.id = id; 
            } 
         
            public boolean equals(Object obj) { 
                final boolean returner; 
                if (obj instanceof ModelElabore) { 
                    return getVmid().equals(((ModelElabore)obj).getVmid()); 
                } else { 
                    returner = false; 
                } 
                return returner; 
            } 
         
            public int hashCode() { 
                return getVmid().hashCode(); 
            } 
         
            private Object getVmid() { 
                if (vmid != null || vmid == null && id == null) { 
                    if (vmid == null) { //Avoid the performance impact 
                                        //of synchronized if we can 
                        synchronized(this) { 
                            if (vmid == null) 
                                vmid = new VMID(); 
                        } 
                    } 
                    return vmid; 
                } 
                return id; 
            } 

Con el uso de la clase VMID, desviamos la API de Java que permite crear un id único para todas las máquinas virtuales Java. Esta API se utiliza normalmente para administrar los garbage collectors (recolectores de basura) distribuidos con objeto de identificar las máquinas virtuales cliente.

Por lo tanto, estamos seguros de tener un identificador único. También es posible utilizar una API de la librería commons de Apache, a saber, la API org.apache.commons.id.uuid, así como la API de Java si está disponible.

Es posible que encontremos esta solución demasiado potente, pero funciona en la mayoría de los casos.

1. Descripción del problema

Hoy en día, hay muchas bases de datos relacionales en el mundo SQL que se utilizan en una amplia variedad de contextos. Las versiones comerciales más populares son Oracle, DB2, SQL Server y Sybase. Existen otras bases de datos gratuitas, como Derby, Firebird, HSQLDB, H2, Ingres, MariaDB, MySQL y PostgreSQL, por nombrar solo las más conocidas. Bases de datos

Normalmente, vamos a utilizar HSQLDB y H2 por sus amplias posibilidades de uso. Esto nos permite tener la base de datos SQL más sencilla posible para hacer una aplicación ligera y realizar pruebas. Estas bases de datos se pueden ejecutar en memoria o con archivos, ofrecen consolas para realizar operaciones en ellas y son muy ligeras en términos de ocupación de memoria o espacio en disco.

Vamos a trabajar preferiblemente con H2, que aporta algunas ventajas valiosas, como el soporte de compatibilidad SQL con Oracle, DB2 y MySQL. Spring ha utilizado HSQLB nativo desde las primeras versiones para ayudarnos a hacer nuestras pruebas unitarias, pero veremos cómo usar H2 en su lugar.

2. Implementación

<dependency> 
           <groupId>com.h2database</groupId> 
           <artifactId>h2</artifactId> 
           <version>2.1.212</version> 
        </dependency> 

public class ConnectH2 { 
           public static void main(String... args) throws Exception {  
              //Eliminamos la base de datos 
              DeleteDbFiles.execute("~", "test", true);  
              //Conexión 
              Class.forName("org.h2.Driver"); 
              Connection connection = DriverManager.getConnection("jdbc:h2:~/ 
        test"); 
              Statement statement = connection.createStatement();  
              //Creamos una tabla 
              statement.execute("create table test(id int primary key, 
        name varchar(255))");  
              //Insertamos un registro 
              statement.execute("insert into test values(1, 'Ediciones ENI')"); 
              //Leemos el registro 
              ResultSet rs; 
              rs = statement.executeQuery("select * from test"); 
              while (rs.next()) {  
              //Lo mostramos 
               System.out.println(rs.getString("name")); 
              }  
              //Close Statement 
              statement.close();  
              //Cierre de la base de datos 
              connection.close(); 
           } 

<web-app> 
           <display-name>Archetype Created Web Application</display-name> 
           <context-param> 
                 <param-name>db.url</param-name> 
                 <param-value>jdbc:h2:~/test</param-value> 
           </context-param> 
           <context-param> 
                 <param-name>db.user</param-name> 
                 <param-value>sa</param-value> 
           </context-param> 
           <context-param> 
                 <param-name>db.password</param-name> 
                 <param-value></param-value> 
           </context-param> 
           <context-param> 
                 <param-name>db.tcpServer</param-name> 
                 <param-value>-tcpAllowOthers</param-value> 
           </context-param> 
           <listener> 
                 <listener-class>org.h2.server.web.DbStarter</listener-class> 
           </listener> 
        </web-app> 

1. Descripción del problema

Más allá de un determinado número de proyectos, la gestión de dependencias se vuelve rápidamente esencial. Muchas herramientas de gestión de dependencias intentan abordar estos problemas. Inicialmente, usamos makefiles que fueron reemplazados por Ant (http://ant.apache.org/: un makefile evolucionado), que, a su vez, fue reemplazado por Maven. Gradle (https://gradle.org/) también se utiliza, pero es más apropiado para proyectos de Android o proyectos que requieren delicadeza a nivel de las acciones que se deben realizar antes, durante y después de las fases de build, test y packaging. A pesar de que el framework Spring utiliza Gradle para administrar sus dependencias de manera interna, usaremos Maven en los ejemplos del libro en aras de la simplificación. Gradle

2. Implementación

Maven es compatible entre Windows, Mac y Unix (Linux). De la misma manera que un makefile, permite generar archivos binarios y, de paso, empaquetarlos a partir de un conjunto de archivos fuente. Utiliza un concepto llamado POM (Project Object Model), que describe un proyecto modular y los pasos necesarios para compilarlo, probarlo, empaquetarlo, instalarlo y desplegarlo. POM

Maven centraliza en espacios de almacenamiento compartidos, llamados «repositorios públicos» en Internet, la mayoría de las versiones de proyectos open source que son dependientes. A través de un repositorio local, pone a disposición de nuestro proyecto una copia de los archivos necesarios a partir del nombre de la dependencia y de su versión, e indica al proyecto dónde encontrar sus dependencias en el repositorio local.

También es posible guardar las versiones de sus propios módulos en el repositorio local para compartirlas entre nuestros diferentes proyectos.

Los proyectos y subproyectos se configuran a través del archivo pom.xml, que se encuentra en el directorio raíz del proyecto. Este archivo describe dependencias e información sobre el proyecto. Es posible hacer una jerarquía de configuración POM donde las propiedades de los POM padres en la jerarquía se sobrecargan en los POM hijos. También es posible externalizar determinados elementos relacionados con la configuración para poder personalizarla en función de los entornos de ejecución de la aplicación.

Con el fin de simplificar el tema, solo veremos el uso simplificado para ilustrar las posibilidades de Spring. No utilizaremos el mecanismo de los POM padres para dar visibilidad y facilidad de compilación y prueba de ejemplos.

3. Instalación de Maven en Windows Maven:instalación

En esta sección se describe la instalación en Windows. Para otras plataformas, siga las recomendaciones de instalación para su sistema operativo en la página que describe la instalación de Maven.

Como hemos mencionado, Maven utiliza un archivo pom.xml para la configuración del paquete que describe las dependencias y cómo compilar, probar y empaquetar la aplicación.

Veremos el contenido de este archivo un poco más adelante.

4. Utilizar un arquetipo Maven

Maven también se puede utilizar para crear un esqueleto de aplicación de forma muy sencilla.

Por ejemplo, podemos crear un proyecto simple con el siguiente comando:

mvn archetype:generate -DgroupId=simple -DartifactId=simple 
        -DpackageName=fr.eni -Dversion=1.0-SNAPSHOT 

En este caso, Maven está en modo interactivo y hace algunas preguntas a las que es suficiente con responder validando el valor predeterminado.

Posteriormente, Maven crea un proyecto «hello world» con el archivo pom.xml asociado.

El siguiente comando lo compila e inicia el programa:

$ mvn exec:java -Dexec.mainClass="simple.App" 
        [INFO] Scanning for projects... 
        [INFO] 
        [INFO] ---------------------------------------------------------- 
        [INFO] Building cap03-simple 1.0-SNAPSHOT 
        [INFO] ---------------------------------------------------------- 
        [INFO] 
        [INFO] --- exec-maven-plugin:1.4.0:java (default-cli) @ cap04-simple --- 
        Hello World! 
        [INFO] ---------------------------------------------------------- 
        [INFO] BUILD SUCCESS 
        [INFO] ---------------------------------------------------------- 
        [INFO] Total time: 6.420 s 
        [INFO] Finished at: 2015-07-21T13:31:25+02:00 
        [INFO] Final Memory: 10M/309M 
        [INFO] ---------------------------------------------------------- 

El comando mvn site genera una documentación completa del proyecto Maven en el directorio target/site.

Otra posibilidad para generar el POM de un proyecto Spring consiste en utilizar el servicio Spring Initializr, en la dirección https://start.spring.io/

5. Contenido del archivo pom.xml en los casos sencillos utilizados en este libro pom.xml

He aquí el contenido del archivo pom.xml de la sencilla aplicación que acabamos de generar, ajustado con alguna información adicional:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
        http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
          <modelVersion>4.0.0</modelVersion> 
          <groupId>simple</groupId> 
          <artifactId>chap05-simple</artifactId> 
          <version>1.0-SNAPSHOT</version> 
          <packaging>jar</packaging> 
          <name>chap04-simple</name> 
          <url>http://maven.apache.org</url> 
           <properties>  
              <java-version>1.8</java-version> 
              <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
              <org.springframework-version>4.3.14-RELEASE 
        </org.springframework-version> 
              <spring.version>4.3.30-RELEASE</spring.version> 
           </properties> 
          <dependencies> 
            <dependency> 
              <groupId>junit</groupId> 
              <artifactId>junit</artifactId> 
              <version>4.13.2</version> 
              <scope>test</scope> 
            </dependency> 
          </dependencies> 
        </project> 
           <build> 
              <finalName>${project.artifactId}</finalName> 
              <plugins> 
                 <plugin> 
                    <groupId>org.apache.maven.plugins</groupId> 
                    <artifactId>maven-compiler-plugin</artifactId> 
                    <version>3.8.1</version> 
                    <configuration> 
                       <source>${java-version}</source> 
                       <target>${java-version}</target> 
                    </configuration> 
                 </plugin> 
                 <plugin> 
                    <groupId>org.apache.maven.plugins</groupId> 
                    <artifactId>maven-surefire-plugin</artifactId> 
                    <version>2.22.2</version> 
                    <configuration> 
                       <includes> 
                          <include>**/*Tests.java</include> 
                       </includes> 
                       <excludes> 
                          <exclude>**/Abstract*.java</exclude> 
                       </excludes> 
                       <junitArtifactName>junit:junit</junitArtifactName> 
                       <argLine>-Xmx512m</argLine> 
                    </configuration> 
                 </plugin> 
                 <plugin> 
                    <groupId>org.apache.maven.plugins</groupId> 
                    <artifactId>maven-dependency-plugin</artifactId> 
                    <executions> 
                       <execution> 
                          <id>install</id> 
                          <phase>install</phase> 
                          <goals> 
                             <goal>sources</goal> 
                          </goals> 
                       </execution> 
                    </executions> 
                 </plugin> 
              </plugins> 
           </build>  

En relación con el proyecto generado, añadimos el hecho de que queremos utilizar Java 8 y UTF-8 (en negrita en el código anterior). También indicamos que usamos Spring en el proyecto.

1. Composición de un bean

Veremos más en detalle cómo funciona un bean en la programación orientada a aspectos con Spring dedicado a AOP.

Para simplificar, un bean se puede considerar como un proxy que extiende un objeto Java. El proxy permite:

El bean está orientado a datos (POJO) o procesamientos, intentando separar estos aspectos en beans especializados.

Por lo tanto, contiene:

Cuando queremos usar un bean Spring, añadimos un miembro de clase e indicamos a Spring que queremos utilizarlo escribiendo la variable con la interfaz correspondiente al Bean. Spring tiene diferentes estrategias para encontrar el Bean adecuado que se va a inyectar.

Un bean se identifica por su nombre y su identificador. Los identificadores pueden tener alias, pero este uso es bastante confuso. Varios beans pueden tener el mismo identificador, por lo que se indicará a Spring cuál debe tener prioridad (@Primary).

2. El singleton y el prototipo

Un singleton, que es el tipo predeterminado de beans, solo tiene una instancia de implementación dentro de un contexto, mientras que el prototipo puede tener varias.

3. Los objetos fundamentales del paquete core

Este paquete gestiona la inyección de dependencias. Utiliza un determinado número de clases, que hay que conocer.

@Data 
        @ToString 
        public class Ejemplo { 
               private String cadena; 
               private Integer entero; 
        } 
         
        public class EjemploEditor extends PropertyEditorSupport { 
            @Override 
            public String getAsText() { 
               Ejemplo ejemplo = (Ejemplo) getValue(); 
                return ejemplo == null ? "" : 
        ejemplo.getCadena()+">"+ejemplo.getEntero(); 
            } 
         
            @Override 
            public void setAsText(String text) throws 
                          IllegalArgumentException { 
                if (StringUtils.isEmpty(text)) { 
                    setValue(null); 
                } else { 
                     Ejemplo ejemplo = new Ejemplo(); 
                   StringTokenizer st = new StringTokenizer(text,">"); 
                   ejemplo.setCadena(st.nextToken()); 
                   ejemplo.setEntero(Integer.parseInt(st.nextToken())); 
                    setValue(ejemplo); 
                } 
            } 
        } 

@Slf4j 
        @Controller 
        public class MiRestController { 
         
               @GetMapping(value = "/test/{id}") 
               public @ResponseBody String test1(@PathVariable String id) { 
                     return id; 
               } 
         
               @GetMapping(value = "/test2/{ex}") 
               public @ResponseBody String test2(@PathVariable Ejemplo ex) { 
                     String ret=ex.toString(); 
         
                     return ret; 
               } 
        } 

http://localhost:8080/test2/aaa%3E1 

Ejemplo(cadena=aaa, entero=1) llamada: 

@Slf4j 
        @Controller 
        public class MiRestController { 
         
               @GetMapping(value = "/test3/{ex}") 
               public @ResponseBody String test3(@PathVariable Ejemplo2 ex) { 
                     String ret=ex.toString(); 
         
                     return ret; 
               } 
         
               @InitBinder 
               public void initBinder(WebDataBinder binder) { 
                   binder.registerCustomEditor(Ejemplo2.class, 
                       new CustomEditorEditor()); 
               } 
        } 

4. PropertyValues

Un PropertyValues contiene varios PropertyValue.

El PropertyValue de un objeto contiene la información y el valor de una propiedad de bean individual. Entre otras cosas, permite gestionar propiedades indexadas de forma optimizada. Se utiliza en los convertidores que veremos en el capítulo Configuración avanzada. También permite especificar si el valor se debe ignorar cuando no existe en el objeto de destino.

Tenga en cuenta que no es necesario que el valor sea de un tipo predefinido porque una implementación BeanWrapper debe ser capaz de gestionar todas las conversiones necesarias. De hecho, este objeto no sabe nada de los objetos a los que se unirá.

5. BranWrapper

BranWrapper es una clase cuyas instancias encapsulan un bean. Permite acceder a las propiedades y manipular un bean.

Por ejemplo, como se especifica en los JavaBeans, podemos acceder a una propiedad usando su nombre en una matriz que indexa las variables de un bean.

Trataremos este objeto con más detalle en el capítulo Configuración avanzada.

6. BeanFactory

Esta factory permite crear un bean desde cero a partir de una interfaz o clase, así como desacoplar la configuración y las dependencias del código funcional del objeto.

Esta factory tiene derivados, como XmlBeanFactory, que consigue su definición de un archivo XML.

Una BeanFactory gestiona la definición de un bean:

BeanFactory rara vez se usa. Es preferible Application-Context, que se analiza a continuación, porque es más versátil.

Para cargar un bean, cargamos su definición usando un archivo XML, por ejemplo, y seguidamente lo recuperamos con el método getBean().

7. La interfaz BeanDefinition

Un BeanDefinition describe una instancia de bean:

Se trata de una interfaz mínima que permite a un BeanFactoryPostProcessor hacer introspección y modificar los valores de propiedad y otros metadatos del bean a medida que la BeanFactory lo crea.

Hablaremos más en detalle sobre BeanFactoryPostProcessor más adelante.

La BeanFactory se ocupa de la inyección de dependencias. Utiliza una BeanDefinition y los PropertyEditors con los PropertyValue para especificar los valores de los atributos.

La inyección de dependencias se puede hacer indicando en una propiedad o en su setter, preferentemente, que se trata de una dependencia a través de los argumentos del constructor, para lo cual indicamos que queremos una inyección de dependencias.

8. PropertyPlaceholderConfigure

Permite externalizar propiedades desde un archivo que contiene las definiciones de los beans. Un elemento de configuración se devuelve a un archivo externo.

PropertyPlaceholderConfigure está en desuso desde Spring 5.2 y se sustituye por PropertySourcesPlaceholderConfigurer.

PropertyPlaceholderConfigure en XML

Archivo de configuración XML para una aplicación con una base de datos a la que se accede a través de JDBC:

<?xml version="1.0" encoding="UTF-8"?> 
        <beans xmlns="http://www.springframework.org/schema/beans" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://www.springframework.org/schema/beans 
          http://www.springframework.org/schema/beans/spring-beans.xsd"> 
          <bean class="org.springframework.beans.factory.config.Property 
        PlaceholderConfigurer"> 
          <property name="locations" value="classpath:jdbc.properties" /> 
          </bean> 
          <bean id="dtSource" destroy-method="close" 
        class="org.apache.commons.dbcp.BasicDataSource"> 
          <property name="driverClassName" value="${jdbc.driverClassName}" /> 
          <property name="url" value="${jdbc.url}" /> 
          <property name="username" value="${jdbc.username}" /> 
          <property name="password" value="${jdbc.password}" /> 
          </bean> 
          <bean id="compteDAO" class="fr.eni.CompteDAO"> 
          <constructor-arg name="dataSource" ref="dtSource"/> 
          </bean> 
        </beans> 

El archivo de configuración de JDBC:

jdbc.properties 
        jdbc.driverClassName=com.mysql.jdbc.Driver 
        jdbc.url=jdbc:mysql://localhost:3306/mabase 
        jdbc.username=root 
        jdbc.password= 

PropertySourcesPlaceholderConfigure en Java

@Configuration  
        @PropertySource("classpath:jdbc.properties") 
        public class AppConfig { 
           @Value("${jdbc.driverClassName}") 
           private String driverClassName; 
           @Value("${jdbc.url}") 
           private String jdbcURL; 
           @Value("${jdbc.username}") 
           private String username; 
           @Value("${jdbc.password}") 
           private String password; 
           @Bean 
           public DataSource getDataSource() { 
          BasicDataSource dataSource = new BasicDataSource(); 
          dataSource.setDriverClassName(driverClassName); 
          dataSource.setUrl(jdbcURL); 
          dataSource.setUsername(username); 
          dataSource.setPassword(password); 
          return dataSource; 
           } 
           @Bean 
           public CompteDAO compteDAO(DataSource dataSource) { 
          return new   CompteDAO(dataSource); 
           } 
           @Bean 
           public static PropertySourcesPlaceholderConfigurer 
        placeHolderConfigurer() { 
          return new PropertySourcesPlaceholderConfigurer(); 
           } 
        } 

Aquí vemos el uso de SpEL (Spring Expression Language):

@Value("${jdbc.password}") 

Indica que debe buscar el valor jdbc.password en la configuración.

9. Los objetos fundamentales del paquete context

ApplicationContext desempeña el mismo papel que un registro JNDI en un servidor Jakarta EE que permite la gestión y manipulación de beans.

Ofrece todas las funcionalidades de un BeanFactory y añade otras.

En resumen, un contexto contiene una agrupación de beans.

Existe el contexto simple y sus derivados:

Se basa en BeanFactory y añade:

Los eventos integrados son:

El espacio de memoria en el que Spring almacena sus elementos de configuración y referencias a objetos gestionados se denomina contexto. Si queremos hacer operaciones usando Spring, necesitamos un contexto de manera obligatoria. Este contexto contiene toda la información sobre los beans Spring configurados. También contiene, entre otras cosas, el estado de estos beans a lo largo del tiempo, así como los vínculos entre los beans y las modificaciones dinámicas realizadas en estos beans para la programación basada en aspectos.

Hay dos facetas complementarias: la primera es la configuración de los beans que indica qué objetos de Java se deben considerar como Spring beans, y la segunda se refiere a la inyección de estos beans en las variables de clase o método, es decir, el uso de los beans en el proyecto. Estas nociones se «mezclan» en algún momento, porque, como veremos, podemos hacer referencia a los beans en otros beans dentro de la configuración.

Para recuperar los beans, utilizamos un cargador de contexto.

10. Relación entre el bean, su BeanFactory o su contexto

Es posible extender el funcionamiento estándar de un bean:

Cuando el bean implementa la interfaz BeanNameAware, Spring llama automáticamente al método void setBeanName(String).

Cuando el bean implementa la interfaz BeanFactoryAware, Spring llama automáticamente al método void setBeanFactory(BeanFactory).

Cuando el bean implementa la interfaz ApplicationContextAware, Spring llama automáticamente al método setApplicationContext (ApplicationContext).

Esto permite recuperar una referencia sobre la parte en cuestión.

He aquí el ciclo de vida de un bean Spring:

1. Configuración mediante un archivo XML XML

Las aplicaciones sencillas o antiguas se configuran directamente en uno o más archivos XML, organizados de forma jerárquica. Por lo general, tenemos un archivo XML principal por contenedor Spring, junto con archivos XML periféricos.

En el siguiente ejemplo, se muestra cómo declarar un bean miServicio que coincida con la clase de implementación miPaquete.MiServicioImpl.

<Beans> 
           <Bean id="miServicio" class="miPaquete.MiServicioImpl"/> 
        </Beans> 

Si la interfaz de la clase del bean es miPaquete.MiServicio, le diremos a Spring que queremos crear un singleton llamado miServicio. Este singleton se puede inyectar en otro bean, es decir, podemos pedirle a Spring que copie la referencia de este objeto en un miembro de otro objeto de nuestra elección:

<bean id="miContenedor" class="miPaquete.MiContenedorImpl"> 
           <property name="servicio" ref="miServicio" /> 
        </bean> 

Este nuevo singleton miContenedor, que tiene la implementación MiContenedorImpl, contendrá como miembro el objeto Service que, a su vez, contendrá el singleton declarado anteriormente.

Podemos decirle a Spring que descubra automáticamente las clases Java que son candidatas a convertirse en beans Spring, especificando en el archivo XML la lista de paquetes que hay que a escanear:

<context:component-scan base-package="miPaquete" /> 

Es posible utilizar una expresión regular para que no tenga que enumerar paquetes a mano, con lo que el funcionamiento depende entonces de convenciones de nomenclatura que tendrán que estar bien documentadas. En caso de error, podemos tener beans de Spring que no eran candidatos; por ejemplo, beans destinados a pruebas y que aún están en producción. En este nivel, la prudencia nos obliga a dotarnos de medios de control para evitar ciertos abusos. 

2. Configuración con anotaciones Anotaciones

Esta reciente evolución de Spring permite configurar Spring directamente en Java de una manera más flexible.

Es habitual que, además de la configuración de Java, tengamos un archivo de configuración XML considerablemente más ligero. Nos aseguraremos de agrupar los elementos de configuración en un solo paquete tanto como sea posible.

El uso de anotaciones para configurar el equivalente del ejemplo anterior, nos da el siguiente código:

package miPaquete;  
        @Configuration 
        public class AppConfig { 
           @Bean 
           public MiServicio myService() { 
              return new MiServicioImpl(); 
           } 
        } 

Esta instrucción indica a Spring que el bean con el id miServicio tiene la clase de implementación MiServicioImpl del paquete miPaquete. Calificamos el tipo de objeto devuelto por su interfaz. Esto especifica que cualquier objeto declarado por esta interfaz puede recibir este servicio por inyección. Es posible poner otro nombre para el bean usando la anotación @Qualifier.

La anotación @Qualifier

class Pollo implements AveCorral{} 
        class Oca implements AveCorral {} 

Podemos elegir la implementación especificando el nombre del bean:

@Autowired 
        Pollo(@Qualifier("pollo") AveCorral aveCorral) { 
          this.aveCorral = aveCorral; 
        } 

El nombre se puede especificar en el objeto, su setter o a través del constructor.

También controlamos el proceso de instanciación del objeto, lo que nos permite personalizar esta creación del objeto. Así que vemos que esta forma de hacer las cosas es mucho más potente que la simple utilización de XML. En caso de problemas, también podemos trazar y depurar el proceso de creación del contexto de la aplicación.

Lista de las principales anotaciones para configurar los beans a partir de anotaciones:

La anotación @ComponentScan:

@ComponentScan(); 

@ComponentScan sin argumentos le dice a Spring que analice el paquete actual y todos sus subpaquetes.

Podemos afinar para especificar los paquetes como argumento de la anotación:

@ComponentScan(basePackages={"paquete1", " paquete2"}) 

3. Configurar los beans de aplicación implícitamente Bean

Por lo tanto, nos podemos basar en una configuración XML o Java para configurar los beans automáticamente, utilizando una facilidad de Spring que permite descubrir los beans basados en un paquete básico y en expresiones regulares.

La declaración implícita es la forma más sencilla de configurar los beans de aplicación. Permite no declararlos uno por uno. En el archivo de configuración XML o en la configuración de Java, especificamos una regla basada en una expresión regular para identificar los beans Spring etiquetados por anotaciones.

La anotación asociada con el bean más simple es @Component. Es posible utilizar la nueva implementación de JSR-330: Dependency Injection for Java, que proporciona anotaciones cuyo funcionamiento se parece al de Spring porque Spring ha interactuado con estas nuevas librerías, pero estas anotaciones son menos avanzadas que las de Spring.

Elegiremos anotaciones JSR-330 @Inject para los casos sencillos y usaremos la anotación Spring @Autowired para los proyectos complejos porque el atributo required no existe para @Inject.

También hay otras anotaciones que indican si el bean está sujeto a AOP o aspectos transaccionales.

4. Configuración por lambdas

Podemos registrar un bean con una lambda:

context.registerBean(MiServicio.class, () -> new MiServicio()); 

Podemos registrar un bean con una lambda añadiendo un nombre significativo:

context.registerBean("miSegundoServicio", MiServicio.class, 
        () -> new MiServicio()); 

También es posible personalizar el bean añadiendo un callback que posicione una propiedad del bean, como el flag autowire-candidate:

context.registerBean("miCallbackServicio", MiServicio.class, 
        () -> new MiServicio(), s -> s.setAutowireCandidate(true)); 

1. Asignación mediante el constructor en XML Mapping XML

El elemento <constructor-arg> o la tecnología c-namespace más compacta introducida en Spring 3 se utiliza para hacer coincidir la firma del constructor en una configuración XML:

<Bean id="disquete" class="unidad.DISQUETE"> < 
         <constructor-arg ref="format" /> 
        </Bean> 

o:

<Bean id=" disquete " class="unidad.DISQUETE" 
        c:cd-ref="format" /> 

Para el «c-namespace», es posible determinar el nombre de la variable constructora por su nombre o por su índice, con un subíndice implícito si solo hay un argumento.

Spring traduce automáticamente del tipo String al posible tipo detectado en la lista de constructores disponibles porque el valor está en String en el archivo de configuración. El transtipado de tipos es arriesgado porque puede ser la fuente de muchos errores; el equivalente en Java de la configuración XML a través de anotaciones es mucho más fiable.

Es posible tener mappings con los constructores que tienen argumentos de tipo colección. El bean se puede instanciar y asignar sus valores de manera automática. Esto es muy práctico, por ejemplo, para crear un datasource preconfigurado.

<Bean id="dataSource" 
           class="org.apache.commons.dbcp.BasicDataSource" 
        destroy-method="close" 
          p:driverClassName="oracle.jdbc.driver.OracleDriver" 
          p:url="jdbc:oracle:thin:@localhost:1521:xe" 
          p:username="MiUsuarioDePrueba" 
          p:password="LaContraseñaDeMiUsuarioDePrueba" 
        /> 

2. Comparación de los métodos de instanciación Instanciación

3. Otras anotaciones de configuración

Hay otras anotaciones relacionadas con la configuración.

@Component ("pojo") 
        public class PojoImpl implements Pojo { 
          @Override 
          public String getNombre() { 
          return "Pojo"; 
          } 
        } 

@Component("pojo") 
        @Primary 
        public class OtroPojoImpl implements Pojo { 
          @Override 
          public String getNombre() { 
          return "Modificado"; 
          } 
        } 

@Configuration 
        public class Config { 
          @Bean 
          public Novio JohnEmployee() { 
          return new Novio("Toto"); 
          } 
          @Bean 
          @Primary 
          public Novio TonyEmployee() { 
          return new Novio("Titi"); 
          } 
        } 

AnnotationConfigApplicationContext context 
          = new AnnotationConfigApplicationContext(Config.class); 
         
        Novio novio = context.getBean(Novio.class); 
        System.out.println(novio); 

@Component 
        @Profile("dev") 
        public class DevConfig implements DatasourceConfig {...} 
         
        @Component 
        @Profile("prod") 
        public class ProdConfig implements DatasourceConfig {...} 

<beans profile="dev"> 
         <bean id="devConfig" 
         class="fr.eni.DevConfig" /> 
        </beans> 

@Configuration 
        public class MiWebApplicationWebInitializer 
          implements WebApplicationInitializer { 
         
          @Override 
          public void onStartup(ServletContext servletContext) throws 
        ServletException {    
          servletContext.setInitParameter( 
            "spring.profiles.active", "dev"); 
          } 
        } 

<context-param> 
          <param-name>contextConfigLocation</param-name> 
          <param-value>/WEB-INF/app-config.xml</param-value> 
        </context-param> 
        <context-param> 
          <param-name>spring.profiles.active</param-name> 
          <param-value>dev</param-value> 
        </context-param> 

export spring_profiles_active=dev 

-Dspring.profiles.active=dev 

@Autowired 
        private ConfigurableEnvironment env;  
        env.setActiveProfiles("dev"); 

@ActiveProfiles("dev") 

String perfilActivo = environment.getActiveProfiles(); 

@Value("${spring.profiles.active}") 
        private String perfilActivo; 

Field f = obj.getClass().getDeclaredField("perfilActivo"); 
        f.setAccessible(true); 

Field field = ReflectionUtils.findField(MyEntity.class, "createDate"); 
        field.setAccessible(true); 

@Bean  
        @ConditionalOnProperty( 
          name = "features.calcul.experimental", 
          matchIfMissing = true) 
        public class calculadorPorDefecto implements Calculador { 
        [...] 
        } 
         
        @Bean  
        @ConditionalOnProperty( 
          name = "features.calcul.experimental") 
        public class CalculadorExperimental implements Calculador { 
        [...] 
        } 

@Configuration 
        public class MiPrimeraConfig { 
         @Bean  
          @ConditionalOnProperty( 
          name = "features.calcul.experimental", 
          matchIfMissing = true) 
          public Calculador calculadorPorDefecto() { 
          return new calculadorPorDefecto() ; 
          } 
         
          @Bean  
          @ConditionalOnProperty( 
            name = "features.calcul.experimental") 
          public Calculador calculadorExperimental() { 
            return new CalculadorExperimental () ; 
          } 
        } 

@DependsOn("connectionActive") 
        class implements StatusDeLaBase {} 

@Bean 
        @DependsOn("connectionActive") 
        Status status() { 
          return new Status(); 
        } 

@Configuration 
        @Lazy 
        class SondaFactoryConfig { 
          @Bean 
          @Lazy(false) 
          Sonde sonda() { 
            return new Sonda(); 
          } 
        } 

@Data 
        public class TopMessageGenerator { 
          private String top; 
        } 

@Bean 
        @Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = 
        ScopedProxyMode.TARGET_CLASS) 
        public TopMessageGenerator requestScopedBean() { 
          return new TopMessageGenerator(); 
        } 

@Bean 
        @RequestScope 
        public TopMessageGenerator requestScopedBean() { 
          return new TopMessageGenerator(); 
        } 

@Controller 
        public class ScopesController { 
          @Resource(name = "requestScopedBean") 
          TopMessageGenerator requestScopedBean; 
         
          @RequestMapping("/scopes/request") 
          public String getRequestScopeMessage(final Model model) { 
          model.addAttribute("previousMessage", requestScopedBean.getMessage()); 
          requestScopedBean.setTop(LocalTime.now().toString()); 
          model.addAttribute("currentMessage", requestScopedBean.getMessage()); 
          return "scopesExample"; 
         } 
        } 

@Bean 
        @Scope(value = WebApplicationContext.SCOPE_SESSION, proxyMode = 
        ScopedProxyMode.TARGET_CLASS) 
        public TopMessageGenerator sessionScopedBean() { 
            return new TopMessageGenerator(); 
        } 

@Bean 
        @SessionScope 
        public TopMessageGenerator sessionScopedBean() { 
            return new TopMessageGenerator(); 
        } 

@Controller 
        public class ScopesController { 
          @Resource(name = "applicationScopedBean") 
          TopMessageGenerator applicationScopedBean; 
         
          @RequestMapping("/scopes/application") 
          public String getApplicationScopeMessage(final Model model) { 
            model.addAttribute("previousMessage", 
        applicationScopedBean.getMessage()); 
            applicationScopedBean.setMessage(LocalTime.now().toString()); 
            model.addAttribute("currentMessage", 
        applicationScopedBean.getMessage()); 
            return "scopesExample"; 
          } 
        } 

@Component 
        @Scope("prototype") 
        public class Notificacion { 
          // mis estados prototype-scoped 
        } 
         
        @Component 
        public class ServiciosAplicativos { 
         
          // ... 
         
          @Lookup 
          public Notificacion getNotificacion() { 
        return null; 
          } 
         
          // ... 
         
        @Test 
        public void whenLookupMethodCalled_thenNewInstanceReturned() { 
          ServiciosAplicativos primero = 
        this.context.getBean(ServiciosAplicativos.class); 
          ServiciosAplicativos second = 
        this.context.getBean(ServiciosAplicativos.class); 
         
          assertEquals(first, second); //singleton 
          assertNotEquals(first.getNotificacion(), second.getNotificacion()); 
        } 

Helice(@Value("3") int numeroPalas) { 
          this.numeroPalas = numeroPalas; 
        } 

@Required 
        void setPeriodo(String periodo) { 
          this.periodo = periodo; 
        } 
        <bean class="fr.eni.Parte"> 
          <property name="period" value="mañana" /> 
        </bean> 

@Import(MiConfig.class) 
        clase TestConfig {} 

public interface ImportSelector { 
               String[] selectImports(AnnotationMetadata importingClassMetadata); 
               @Nullable 
               default Predicate<String> getExclusionFilter() { 
                      return null; 
               } 
        } 

@Configuration 
        @ImportResource("classpath:/anotaciones.xml") 
        class SondaFactoryConfig {} 

1. El Proyecto Maven Maven

mvn archetype:generate -DgroupId=fr.eni.editions 
        -DartifactId=mappingApp -DarchetypeArtifactId=maven-archetype-quickstart 
        -DinteractiveMode=false 

Pondremos en estos directorios los archivos de configuración de Spring y el sistema de registro.

2. Archivo de configuración de Spring Archivo de configuración

Crearemos un archivo Spring llamado applicationContext.xml y lo colocaremos en el directorio src/main/resources/Spring/.

<?xml version="1.0" encoding="UTF-8"?> 
        <beans default-lazy-init="true" 
        xmlns="http://www.springframework.org/schema/beans" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:context="http://www.springframework.org/schema/context" 
        xmlns:jdbc="http://www.springframework.org/schema/jdbc" 
           xsi:schemaLocation=" 
             http://www.springframework.org/schema/beans 
        http://www.springframework.org/schema/beans/spring-beans-4.1.xsd 
             http://www.springframework.org/schema/jdbc 
        http://www.springframework.org/schema/jdbc/spring-jdbc-4.1.xsd 
             http://www.springframework.org/schema/context 
        http://www.springframework.org/schema/context/spring-context-4.1.xsd"> 
           <context:component-scan base-package="fr.eni" /> 
        </beans> 

En este archivo, indicamos que los beans anotados para tener en cuenta están en el paquete "fr.eni" y en todos sus subpaquetes.

3. Dependencia de Spring Core y sistema de registro Spring Core Log

Spring es autónomo en términos de dependencias, con la excepción del framework de registros de actividad, de manera que se pueda utilizar el sistema de registro del proyecto integrando el motor Spring. Dependencias

Spring utiliza por defecto el sistema commons-logging de Spring Core. Para tener su propio sistema de logging, debe excluir el common.logging y sustituirlo por Logback porque, de hecho, es mucho más práctico y más potente que Log4j.

Usaremos SLF4J (http://www.slf4j.org/) para interactuar con Logback en las siguientes versiones:

Esto proporciona las siguientes dependencias en el archivo pom.xml:

   <dependency> 
          <groupId>org.springframework</groupId> 
          <artifactId>spring-core</artifactId> 
          <version>5.3.18.RELEASE</version> 
          <exclusions> 
             <exclusion> 
              <groupId>commons-logging</groupId> 
              <artifactId>commons-logging</artifactId> 
            </exclusion> 
          </exclusions> 
          </dependency> 

4. Dependencia de librerías de pruebas unitarias Pruebas:unitarias

Veremos los detalles de las pruebas unitarias y las pruebas de integración en un capítulo dedicado. De hecho, Spring es muy práctico para hacer pruebas. Usaremos jUnit junto con org.easytesting para este ejemplo. Utilizando el scope <test>, indicamos que las dependencias de este scope solo estarán presentes durante las pruebas.

Extracto del archivo pom.xml

   <dependency> 
          <groupId>junit</groupId> 
          <artifactId>junit</artifactId> 
          <version>4.13.2</version> 
          <scope>test</scope> 
           </dependency> 
           <dependency> 
          <groupId>org.easytesting</groupId> 
          <artifactId>fest-assert</artifactId> 
          <version>1.4</version> 
           <dependency> 

Spring-test y Spring-context también se deben integrar en el scope test. De hecho, son específicos de las pruebas:

   <dependency> 
          <groupId>org.springframework</groupId> 
          <artifactId>spring-test</artifactId> 
          <version>5.3.18.RELEASE</version> 
          <scope>test</scope> 
           </dependency> 
           <dependency> 
          <groupId>org.springframework</groupId> 
          <artifactId>spring-context</artifactId> 
          <version>5.3.18.RELEASE</version> 
          <scope>test</scope> 
           </dependency> 

5. Ejemplo que ilustra el uso de los logs Log

Probamos esta configuración añadiendo simples logs en la clase de prueba AppTest:

@RunWith(SpringJUnit4ClassRunner.class) 
        @ContextConfiguration(locations = { 
        "classpath*:spring/applicationContext-test.xml" }) 
        public class AppTest 
        [...] 
           @Test 
           public void testApp(){ 
          logger.info("Basic info Spring Test"); 
          logger.debug("Basic debug Spring Test"); 
          simpleService.printHello(); 
          assertThat( true ); 
           } 

Lo único que tenemos que hacer es modificar el archivo de configuración de los logs logback.xml en el archivo src/tests/resources:

<?xml version="1.0" encoding="UTF-8"?> 
        <configuration> 
        [...] 
           <logger name="fr.eni.editions" additivity="false"> 
          <level value="DEBUG" /> 
          <appender-ref ref="consoleAppender" /> 
           </logger> 
        </configuration> 

6. Archivo de configuración específico de las pruebas Archivo de configuración Pruebas

Crearemos un archivo de configuración Spring applicationContext-test.xml para realizar pruebas en /src/test/resources/spring.

<?xml version="1.0" encoding="UTF-8"?> 
        <Beans default-lazy-init="true" 
        xmlns="http://www.springframework.org/schema/Beans" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:context="http://www.springframework.org/schema/context" 
        xmlns:jdbc="http://www.springframework.org/schema/jdbc" 
           xsi:schemaLocation=" 
             http://www.springframework.org/schema/Beans 
        http://www.springframework.org/schema/Beans/Spring-Beans-4.1.xsd 
             http://www.springframework.org/schema/jdbc 
        http://www.springframework.org/schema/jdbc/Spring-jdbc-4.1.xsd 
             http://www.springframework.org/schema/context 
        http://www.springframework.org/schema/context/Spring-context-4.1.xsd"> 
           <import resource="classpath*:Spring/applicationContext.xml" /> 
        </Beans> 

Este archivo se parece al archivo principal. Por ahora, solo estamos importando el archivo principal. En este archivo podremos añadir los elementos de configuración específicos de las pruebas.

El registro de la actividad se genera cuando el programa se ejecuta:

15:45:56.278 [main] INFO fr.eni.editions.AppTest - Basic Spring Test 

Es posible ver todos los logs de depuración de Spring descomentando el appender de los logs de Spring: el archivo de log generado tiene una longitud de más de cien líneas.

Un buen ejercicio será leer este log en detalle.

Es posible cargar la javadoc y los recursos de dependencias Maven desde la configuración Maven del proyecto. A continuación, podemos seguir paso a paso la ejecución de los métodos del motor Spring para descubrir su funcionamiento interno. Este es un ejercicio muy bueno para ver parte del funcionamiento interno del framework.

1. Uso de ExpressionParser

ExpressionParser se utiliza para evaluar una expresión.

Rara vez lo usamos directamente, pero Spring lo utiliza muy a menudo con las cadenas que le enviamos.

ExpressionParser parser = new SpelExpressionParser (); 
        Expression exp = parser.parseExpression ( "'Hola a'.concat 
        (' todos')"); 
        String message = (String) exp.getValue (); 

Por ejemplo, aquí concatenamos las cadenas «hola a » y «todos».

Se puede acceder a los miembros y métodos de los objetos a través de una cadena de llamadas, utilizando «.».

Por ejemplo:

"'Hola a todos'.bytes.length" 

invoca ’getBytes().length’.

El método getValue tiene la firma:

public <T> T getValue(Class<T> desiredResultType). 

Esto hace posible no especificar el tipo.

Normalmente, usamos ExpressionParser a través de un objeto pivote o raíz:

Coche coche = new Coche ( "Ford" , "blanco" ); 
        ExpressionParser parser = new SpelExpressionParser (); 
        Expression exp = parser.parseExpression ( "marca" ); 
        EvaluationContext context = new StandardEvaluationContext (coche); 
        String marca = (String) exp.getValue (context); 

A continuación, getValue se realiza en un EvaluationContext específico.

2. EvaluationContext

Si no se especifica de manera explícita, de forma predeterminada usamos Standard EvaluationContext, que utiliza la reflexividad y la introspección de Java para manipular objetos.

Con StandardEvaluationContext podemos especificar el objeto raíz que se debe evaluar usando el método setRootObject() o pasando el objeto raíz al constructor.

StandardEvaluationContext elcontext = new StandardEvaluationContext(); 
        TestBean tb = new TestBean(); 
        tb.aaa = "cccc"; 
        Map map = LangUtils.asMap("ccc", "dddd", "userName", "testUser"); 
        map.put("map", LangUtils.asMap("ccc", "dddd", "tb", tb)); 
        elcontext.setRootObject(map); 
        Expression exp = parser.parseExpression("['ccc']"); 
        Object val = (String)exp.getValue(elcontext, String.class); 
        System.out.println("val: " + val); 
        Assert.assertEquals("dddd", val); 

También es posible especificar variables y funciones que se utilizan en la expresión, con ayuda de los métodos setVariable() y registerFunction().

A continuación, se muestra el método setVariable():

ExpressionParser parser = new SpelExpressionParser(); 
        Expression spelExpression = parser.parseExpression("#aMap['un'] eq 1"); 
        StandardEvaluationContext ctx = new StandardEvaluationContext(); 
        ctx.setVariables(new HashMap<String, Object>() { 
        { 
          put("aMap", new HashMap<String, Integer>() { 
               { 
                 put("uno", 1); 
                 put("dos", 2); 
                 put("tres", 3); 
               } 
          }); 
        } 
        }); 
        boolean resultado = spelExpression.getValue(ctx, Boolean.class); 
        assertTrue(resultado); 

Para registerFunction():

SpelExpressionParser parser = new SpelExpressionParser(); 
        StandardEvaluationContext ctx = new StandardEvaluationContext(); 
        ctx.registerFunction("repeat",ExpressionLanguageScenarioTests.class. 
        getDeclaredMethod("repeat",String.class)); 
        Expression expr = parser.parseRaw("#repeat('hello')"); 
        Object value = expr.getValue(ctx); 
        assertEquals("hellohello", value); 

Finalmente, con StandardEvaluationContext podemos registrar los ConstructorResolvers, MethodResolvers y PropertyAccessors personalizados para ampliar la forma en que SpEL evalúa las expresiones.

3. Uso con @Value

En la actualidad, SpEL se utiliza principalmente a través de la anotación @Value. 

Su uso más sencillo es a través del #, que indica que queremos una evaluación:

@Value("#{1 + 2}") // 3 
        private double adicion; 
         
        @Value("#{0 == 0}") // true 
        private boolean equal; 

Usando un regex:

@Value("#{'123abc' matches '\\d+' }") // false 
        private boolean resultadoNoNumerico; 

Acceso a un miembro de bean:

@Value("${jdbc.url}") 

El bean puede tener sus valores asignados en un archivo de propiedades a través de PropertySourcesPlaceholderConfigurer.

El acceso a un miembro estático de un objeto estático:

@Value("#{ObjetoEstatico.variableEstatica}") 

1. Aspectos generales

Spring fue diseñado originalmente para evitar el uso de los EJB, que originalmente eran inmaduros. En sus primeras versiones, Spring permitía una gestión simplificada de los EJB. Incluso hoy en día, los proyectos continúan usando Spring 3 con servidores Java JEE 6, o incluso Spring 2 asociado con un servidor Java JEE 5, generalmente con un framework casero. Algunas veces se evita la migración si las modificaciones de código son menores. Encontramos en Spring 2 y 3 casi todo lo que hay en Spring 4, excepto las anotaciones. De hecho, en la medida de lo posible, Spring ha intentado llevar las evoluciones de la versión actual en las versiones anteriores. En todas sus versiones, Spring funciona muy bien en la mayoría de los servidores J2EE, Java EE y Jakarta EE (siempre que utilice la versión que corresponda al servidor empleado).

En la práctica, los «problemas» llegan con bastante rapidez. Para empezar, están las implementaciones «propietarias» de las JVM. Una JVM de IBM no tiene los mismos errores o fallos que una JVM de Oracle. Esto significa que el código no es realmente portable. También es necesario tener en cuenta el ritmo de las versiones correctivas y las dificultades de hacer que los parches estén disponibles en los diferentes entornos.

Luego están las partes personalizadas: WebSphere, WebLogic y jBoss. Estas proponen una parte común desde un punto de vista de las especificaciones, pero cada una tendrá sus sutilezas para implementarlas y, por lo tanto, será necesario conocerlas. Además, también ofrecen partes diferenciadoras que facilitarán enormemente la vida de los desarrolladores, pero los vincularán permanentemente con un proveedor de servidores. Su objetivo es vender un paquete con máquinas, licencias, etc. Estos puentes, generalmente, permiten llamar al código «Legacy» desde el código Java.

IBM ofrece un puente con sus mainframes que permiten utilizar IMS, CISC, etc., junto con Java. WebLogic ofrece un puente con Tuxedo y workflows basados en MDB (Message Driven Bean). JBoss propone innovaciones, JBoss Rules, Hibernate o pocas interconexiones propietarias. JBoss se utiliza mucho en contenedores docker con Kubernetes y OpenShift.

En función del cliente que tiene que elegir un servidor de aplicaciones específico, buscamos a los especialistas informáticos adecuados; por ejemplo, una implementación de IBM o JBoss desde el desarrollador hasta el arquitecto. No había servidores genéricos que se pudieran usar en producción.

Spring se centró en las áreas comunes de estos servidores empresariales, con código portable. Como ejemplo, podemos considerar un administrador de transacciones que funciona de forma diferente en diferentes servidores. Spring se encarga de interactuar con los diferentes servidores. Por ejemplo, Juergen Hoeller del equipo Spring, adaptó el código de Spring para que funcionara con todas las versiones de WebSphere, a pesar de que la gestión de transacciones en el equipo de Spring ha cambiado drásticamente entre diferentes versiones.

Nuestros clientes que utilizan Spring podrían recurrir a especialistas informáticos generalistas, interoperativos y polivalentes, desde desarrolladores hasta arquitectos.

Desde el inicio, Spring se ha integrado con J2EE. Java ha tomado algunos elementos de Spring, pero estamos lejos de ello. Spring puede innovar de manera más simple porque es un framework independiente de los servidores de aplicaciones. Los utiliza, se basa en ellos, pero no necesita probar o hacer compatibles sus evoluciones con librerías específicas. Solo se hace evolucionar una versión, en lugar de una por fabricante. Las facades de Spring (o factory) son «más simples» que el código llamado por estas.

Los servidores Java EE a menudo han adaptado partes importantes de las JVM, como el class loader (cargador de clases), la gestión de memoria, los procesos, etc., para sus propias necesidades. Por lo tanto, es necesario tener en su estación de desarrollo y en su plataforma de integración continua un entorno muy cercano al utilizado en producción para evitar efectos secundarios. Por ejemplo, la administración de charsets UTF-8 y de certificados pueden provocar comportamientos no deseados.

Así que Java EE evolucionó tomando ideas de Spring. Hoy en día encontramos gran parte de las innovaciones de Spring incluidas en Java EE. Los conceptos son similares, pero la implementación es diferente.

Aunque Spring puede presumir de fiabilidad por disponer de millones de usuarios, algunas veces tenemos implementaciones relativamente jóvenes e incompletas de los conceptos en Java EE. El sitio web https://stackoverflow.com, generalmente, tiene una respuesta a los problemas relativos a Spring, pero este no siempre es el caso para los servidores Java EE.

Ahora es posible crear una aplicación Jakarta EE sin librerías propietarias, sin Spring, sin librerías de terceros como las librerías Struts, Apache (commons, etc.), sin SPA (Single Page Applications). Algunas tienen éxito, pero es raro.

Java EE es un conjunto de especificaciones que los proveedores de servidores Java deben implementar. Algunos de estos fueron implementados por servidores ligeros como Tomcat o Jetty. Por lo tanto, hemos aislado esta parte de las especificaciones a través de los perfiles en el webprofile, que es un subconjunto de las especificaciones generales contenidas en la parte completa (platform).

Algunos frameworks, como Hessian, se consideran parte de la esfera Java EE sin tener una especificación.

Tenga en cuenta que las especificaciones de Java para la parte Enterprise todavía se controlan en el lado de Jakarta EE. Spring continúa e integra estas evoluciones de versión.

En la parte webprofile de Jakarta EE 8, encontramos:

En la parte completa, encontramos una parte obligatoria y otra opcional, además de la parte webprofile:

Como opción:

En el caso de una aplicación Java desplegada en un servidor Java EE o Jakarta EE, tenemos la opción de una funcionalidad para usar:

Spring interactúa con los servidores que implementan estas especificaciones. Algunas veces, Spring todavía no está interconectado con los componentes correspondientes a la última versión de una especificación.

Spring gestiona en su parte Spring Integration:

En este capítulo, solo detallamos la parte Web Service JAX-WS y el uso de los EJB. Las llamadas RMI y Hessian son demasiado específicas. Solo hay que recordar que RMI se puede usar para llamar a componentes CORBA y que la especificación RMI-IIOP se elimina en Jakarta EE 9. Por su parte, Hessian permite crear servicios web utilizando archivos binarios.

No detallaremos la interfaz con JMX y JMX remoto (servidor) y JCA CCI, que rara vez se usan fuera de los frameworks.

2. Web services

Para los web services, Spring expone o utiliza los web services JAX-WS a través de su módulo Spring WS, actualmente en la versión 3.1.1.RELEASE, disponible en la dirección https://spring.io/projects/spring-ws

Spring permite exponer un web service a través de un servlet, de un servidor integrado y a través de JAX-WS RI GlassFish (no se detalla aquí porque no es portable).

@WebService(serviceName="MiServicio") 
        public class AccountServiceEndpoint extends SpringBeanAutowiringSupport { 
            @Autowired 
            private RegionService regionService; 
         
            @WebMethod 
            public void insertRegion(Region region) { 
                biz.insertAccount(acc); 
            } 
         
            @WebMethod 
            public Regions[] getRegions(String nombre) { 
                return regionService.getAccounts(name); 
            } 
        } 

<bean class="org.springframework.remoting.jaxws.SimpleJaxWsServiceExporter"> 
            <property name="baseAddress" value="http://localhost:8080/"/> 
        </bean> 
         
        <bean id="regionServiceEndpoint" class="ejemplos.RegionServiceEndpoint"> 
            ... 
        </bean> 

@WebService(serviceName="RegionService") 
        public class RegionServiceEndpoint {  
          
            @Autowired 
            private RegionService regionService; 
         
            @WebMethod 
            public void insertRegion(Region region) { 
                regionService.insertRegion(region); 
            } 
            @WebMethod 
            public List<Region> getRegionss(String nombre) { 
                return regionService.getRegions(nombre); 
            } 
        } 

<bean id="regionWebService" 
        class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean"> 
            <property name="serviceInterface" value="ejemplos.RegionService"/> 
            <property name="wsdlDocumentUrl" 
        value="http://localhost:8888/RegionServiceEndpoint?WSDL"/> 
            <property name="namespaceUri" value="https://ejemplos/"/> 
            <property name="serviceName" value="RegionService"/> 
            <property name="portName" value="RegionServiceEndpointPort"/> 
        </bean> 

<bean id="cliente" class="ejemplos.RegionClienteImpl"> 
            ... 
            <property name="servicio" ref="regionWebService"/> 
        </bean> 

public class RegionClienteImpl { 
            private RegionService service; 
            public void setService(RegionService service) { 
                this.service = service; 
            } 
            public void inserer() { 
                service.insertRegion(...); 
            } 
        } 

3. Los EJB

En la mayoría de los casos, es más fácil sustituir los EJB por singletons Spring (@Service). Sin embargo, esto último no impide el uso de los EJB, sino que incluso facilita su acceso y sus implementaciones, ya sean variantes de EJB local, EJB remoto o POJO.

En sí mismo, EJB es bastante sencillo, pero su configuración y uso en un servidor Java EE o Jakarta EE es complejo. En nuestros ejemplos para este capítulo, utilizamos un servidor Wildfly en la versión wildfly-26.0.1.Final. Se compone de un EAR que contiene un WAR. La aplicación Spring Boot está en este WAR. Utiliza los EJB contenidos en otro EAR.

El ejemplo proporcionado en los archivos descargables permite experimentar y ampliar el estudio de este asunto.

@Stateless 
        public class StatelessSessionBeanImpl implements StatelessSessionBean { 
         
            public String decirHola() { 
                return ("Hola"); 
            } 
        } 

@Stateful 
        public class StatefulSessionBeanImpl implements StatefulSessionBean { 
         
            private String usuario; 
         
            public void login(String usuario) { 
                this.usuario = usuario; 
            } 
         
            public String decirHola() { 
                if (usuario == null) { 
                    return ("Hola"); 
                } 
                return ("Hola " + usuario + " !"); 
            } 
        } 

<pluginGroups> 
         [...] 
         <pluginGroup>org.wildfly.plugins</pluginGroup> 
         </pluginGroups> 

<dependency> 
            <groupId>javax</groupId> 
            <artifactId>javaee-api</artifactId>  
            <version>8.0.1</version> 
            <scope>provided</scope> 
        </dependency>  
          
        <dependency> 
            <groupId>org.wildfly.bom</groupId> 
            <artifactId>wildfly-jakartaee8-with-tools-builder</artifactId> 
            <version>20.0.1.Final</version> 
            <scope>import</scope> 
            <type>pom</type> 
        </dependency> 

@Remote 
         public interface Hola { 
         String getHola(); 
        } 

@Stateless(name = "Hola") 
        public class HolaBean implements Hola { 
         
            @Resource 
            private SessionContext context; 
         
            @Override 
            public String getHola() { 
                return "Hola a ti"; 
            } 
        } 

<plugin> 
            <artifactId>maven-ejb-plugin</artifactId> 
            <version>2.4</version> 
            <configuration> 
                <ejbVersion>3.2</ejbVersion> 
            </configuration> 
        </plugin> 

Empaquetado: mvn package 
        Despliegue: mvn wildfly:deploy 

<dependency> 
            <groupId>org.wildfly</groupId> 
            <artifactId>wildfly-ejb-client-bom</artifactId> 
            <type>pom</type> 
            <scope>import</scope> 
        </dependency> 
         
        <dependency> 
            <groupId>com.baeldung.ejb</groupId> 
            <artifactId>ejb-remote</artifactId> 
            <type>ejb</type> 
        </dependency> 

remote.connections=default 
        remote.connection.default.host=127.0.0.1 
        remote.connection.default.port=8080 
        remote.connection.default.connect.options.org.xnio.Options. 
        SASL_POLICY_NOANONYMOUS = false 
        remote.connection.default.connect.options.org.xnio.Options. 
        SASL_POLICY_NOPLAINTEXT = false 
        remote.connection.default.connect.options.org.xnio.Options. 
        SASL_DISALLOWED_MECHANISMS = ${host.auth:JBOSS-LOCAL-USER} 
        remote.connection.default.username=myusername 
        remote.connection.default.password=mypassword 

ejb:${appName}/${moduleName}/${distinctName}/ 
        ${beanName}!${viewClassName} 

public Hola lookup() throws NamingException { 
            String appName = ""; 
            String moduleName = "remote"; 
            String distinctName = ""; 
            String beanName = "Hola"; 
            String viewClassName = Hola.class.getName(); 
            String toLookup = String.format("ejb:%s/%s/%s/%s!%s", 
              appName, moduleName, distinctName, beanName, viewClassName); 
            return (Hola) context.lookup(toLookup); 
        } 

public void createInitialContext() throws NamingException { 
            Properties prop = new Properties(); 
            prop.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); 
            prop.put(Context.INITIAL_CONTEXT_FACTORY, 
              "org.jboss.naming.remote.client.InitialContextFacto[ERROR] 
            prop.put(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080"); 
            prop.put(Context.SECURITY_PRINCIPAL, "testUser"); 
            prop.put(Context.SECURITY_CREDENTIALS, "admin1234!"); 
            prop.put("jboss.naming.client.ejb.context", false); 
            context = new InitialContext(prop); 
        } 

import javax.ejb.Remote; 
         
         
        @Remote 
        public interface OperationImplRemote { 
        int multiplier(int a,int b); 
        } 
         
        @Stateless(mappedName="st1") 
        public class OperationImpl implements OperatonImplRemote { 
          public int multiplicar(int a,int b){ 
              return a*b; 
          } 
        } 
         
        public class Test { 
          public static void main(String[] args)throws Exception { 
            Context context=new InitialContext(); 
            AdderImplRemote remote=(AdderImplRemote)context.lookup("st1"); 
            System.out.println(remote.multiplicar(2,3)); 
          } 
        } 

public interface HolaDelegate { 
         HolaTO hola(String nombre); 
        } 

<bean id="holaDelegateSimple" lazy-init="true" 
             class="org.springframework.ejb.access. 
        SimpleRemoteStatelessSessionProxyFactoryBean"> 
         
           <property name="jndiName" value="ejb/Hello" /> 
           <property name="businessInterface" 
                     value="fr.eni.HelloDelegate" /> 
        </bean>  

final ApplicationContext ctx ; 
        ctx = new ClassPathXmlApplicationContext(new String[] 
        {"ejb-client.xml"}); 
         
        HolaDelegate del = 
        (HolaDelegate)ctx.getBean("holaDelegateSimple"); 
        HolaTO hi = del.hola("tú")); 

public class ExceptionHandlingInterceptor implements MethodInterceptor { 
           public Object invoke(MethodInvocation invocation) throws Throwable { 
               try { 
                   return invocation.proceed(); 
               } catch (ServerException e) { 
                   throw new BusinessDelegateException( 
                           "Problema de conexión al servidor", e.getCause()); 
               } catch (Exception e) { 
                   throw new BusinessDelegateException(e); 
               } 
           } 
        } 

<bean id="holaDelegate" 
              class="org.springframework.aop.framework.ProxyFactoryBean"> 
            <property name="proxyInterfaces"> 
                <value>springdelegate.BonjourDelegate</value> 
            </property> 
            <property name="target"> 
                <ref local="holaDelegateSimple"/> 
            </property> 
            <property name="interceptorNames"> 
               <list> 
                   <value>exception</value> 
               </list> 
            </property> 
        </bean> 

final ApplicationContext ctx; 
        ctx = new ClassPathXmlApplicationContext(new String[] 
        {"ejb-client.xml"}); 
        HolaDelegate del = (HelloDelegate)ctx.getBean("holaDelegate"); 
        HolaTO hi = del.hola("tu")); 

public interface MyComponent { 
         ... 
        } 

private MyComponent myComponent; 
         
        public void setMyComponent(MyComponent myComponent) { 
            this.myComponent = myComponent; 
        } 

<bean id = "myComponent" 
                class = 
        "org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean"> 
            <property name = "jndiName" value = "ejb / myBean" /> 
            <property name = "businessInterface" value = "com.mycom.MyComponent" /> 
        </bean> 
        <bean id = "myController" class = "com.mycom.myController"> 
            <property name = "myComponent" ref = "myComponent" /> 
        </bean> 

<jee: local-slsb id = "myComponent" jndi-name = "ejb / myBean" 
                business-interface = "com.mycom.MyComponent" /> 
         
        <bean id = "myController" class = "com.mycom.myController"> 
            <property name = "myComponent" ref = "myComponent" /> 
        </bean> 

1. Archivos de recursos estándares

Los archivos y las URL que hacen referencia a un archivo se pueden leer de manera estándar, como en el siguiente ejemplo:

@Log 
        public class Recursos1 { 
           public static void procesarRecurso(Resource resource) { 
              try { 
                 InputStream is = resource.getInputStream(); 
                 BufferedReader br = new BufferedReader(new 
        InputStreamReader(is)); 
                 String linea; 
                 while ((linea = br.readLine()) != null) { 
                    log.info(linea); 
                 } 
                 br.close(); 
              } catch (IOException e) { 
                 e.printStackTrace(); 
              } 
           } 
           public static void main(String[] args) throws IOException { 
              Resource r0 = new FileSystemResource("src/main/resources/fr/ 
        eni/editions/recurso.txt"); 
              procesarRecurso(r0); 
         
              String 
        archivo=System.getProperty("user.dir")+"/src/main/resources/fr/ 
        eni/editions/recurso.txt"; 
              log.info("Archivo:"+archivo); 
         
              Resource r1 = new UrlResource("file:"+archivo); 
              procesarRecurso(r1); 
              Resource r2 = new ClassPathResource("fr/eni/editions/ 
        recurso.txt"); 
              procesarRecurso(r2); 
           } 

Tenemos un método processResource en la clase Recursos1 con el argumento resource de tipo Resource. Este método procesa el recurso y se retomará en los ejemplos siguientes.

La primera parte abre el archivo del ejemplo con un FileSystemResource y lo procesa con el método procesarRecurso.

La segunda parte del ejemplo abre el archivo usando un UrlResource y, a continuación, lo procesa con el método procesarRecurso.

Por lo tanto, el primero es un archivo, y el segundo, una URL que apunta a un archivo.

La clase UrlResource también permite actuar sobre recursos de otros tipos, como flujos HTTP, etc.

2. Archivos de recursos cargados con el contexto Spring

Podemos utilizar las facilidades de Spring para cargar recursos.

Reutilizamos el procesamiento de recursos del primer ejemplo.

@Log 
        public class Recursos2 { 
           public static void procesarRecurso(Resource resource) { 
         [...] 
           } 
           public static void main(String[] args) { 
              ApplicationContext ctx = new ClassPathXmlApplicationContext( 
                    new String[] { "applicationContext.xml" }); 
              String rep=System.getProperty("user.dir"); 
              log.info("Rep actual:"+rep); 
         
              Resource r0 = ctx 
         
        .getResource("file:"+rep+"/src/main/resources/fr/eni/editions/ 
        recurso.txt"); 
              procesarRecurso(r0); 
              Resource r1 = ctx 
         
        .getResource("classpath:fr/eni/editions/recurso.txt"); 
              procesarRecurso(r1); 
              Resource r2 = ctx 
         
        .getResource("url:http://echo.jsontest.com/key/value/one/two"); 
              procesarRecurso(r2); 
         
           } 

El método getResource de ApplicationContext permite cargar cualquier tipo de recurso especificando el protocolo File o HTTP. Utilizamos el mismo método, independientemente del tipo de recurso el código es más sencillo. Es como una facade que enmascara la complejidad subyacente.

3. Archivos de recursos cargados con un servicio ResourceLoaderAware

Podemos usar las capacidades de Spring para cargar los recursos y exponerlos en un servicio. A continuación, el servicio que implementa ResourceLoaderAware expone dos métodos:

public void setResourceLoader(ResourceLoader resourceLoader) 

y

public Resource getResource(String location) 

Spring inyecta automáticamente el recurso en el bean y lo hace disponible con el método getResource.

Reutilizamos el procesamiento de recursos del primer ejemplo para procesar el recurso.

@Log 
        public class Recursos3 { 
         
           public static void procesarRecurso(Resource resource) { 
        [...] 
           } 
         
           public static void main(String[] args) { 
              ApplicationContext ctx = new ClassPathXmlApplicationContext( 
                    new String[] { "applicationContext.xml" });  
              RecursoHelperService svc = 
        (RecursoHelperService)ctx.getBean("recursoHelperService"); 
         
         
              String rep=System.getProperty("user.dir"); 
              log.info("Rep actual:"+rep); 
         
              Resource r0 = svc.getResource("file:"+rep+"/src/main/resources/ 
        fr/eni/editions/recurso.txt"); 
              procesarRecurso(r0); 
              Resource r1 = svc 
         
        .getResource("classpath:fr/eni/editions/recurso.txt"); 
              procesarRecurso(r1); 
              Resource r2 = svc 
         
        .getResource("url:http://echo.jsontest.com/key/value/one/two"); 
              procesarRecurso(r2); 
           } 

public class RecursoHelperService implements ResourceLoaderAware 
           private ResourceLoader resourceLoader; 
           public void setResourceLoader(ResourceLoader resourceLoader) { 
              this.resourceLoader = resourceLoader; 
           } 
           public Resource getResource(String location){ 
              return resourceLoader.getResource(location); 
           } 

1. Built-in converters

Un built-in converter es un conversor integrado. Usamos la clase Spring GenericConversionService para tener los conversores estándar. Esta clase permite disponer de un servicio de conversión que se puede extender con conversores personalizados.

En el siguiente ejemplo, se muestra cómo utilizar un DefaultConversionService que implementa la clase de uso general GenericConversionService.

Declaración del conversor genérico

GenericConversionService cs = new DefaultConversionService(); 

Boolean buleano = cs.convert("true", Boolean.class); 
        assertTrue(buleano); 
         
        buleano = cs.convert("no", Boolean.class); 
        assertFalse(buleano); 
         
        Caracter car = null; 
        car = cs.convert("Z", Caracter.class); 
        assertEquals(new Caracter('Z'), car); 
         
        try { 
           car = cs.convert("Exception", Caracter.class); 
           fail("Debe generar una excepción porque la cadena no es un 
        carácter"); 
        } catch (ConversionFailedException aExp) { 
        assert (aExp.getMessage() 
        .contains("Failed to convert from type java.lang.String to type 
        java.lang.Caracter")); 
        } 
        Integer entero = cs.convert("43210", Integer.class); 
        assertEquals(new Integer(43210), entero); 
         
        Float flotante = cs.convert("123.456f", Float.class); 
        assertEquals(new Float(123.456f), flotante); 

String[] tabCadena = cs.convert("Redondo,Cuadrado,Triangular", 
                               String[].class); 
        assertEquals("Redondo", tabCadena[0]); 
        assertEquals("Cuadrado", tabCadena[1]); 
        assertEquals("Triangular", tabCadena[2]); 
         
        List<String> lstCadena = cs.convert( 
                   "Redondo,Cuadrado,Triangular", List.class); 
        assertEquals("Redondo", lstCadena.get(0)); 
        assertEquals("Cuadrado", lstCadena.get(1)); 
        assertEquals("Triangular", lstCadena.get(2)); 

lstCadena = conversionService.convert( 
                  new String[]{"Redondo","Cuadrado","Triangular"}, List.class); 

String formas = cs.convert( 
                  new String[]{"Redondo","Cuadrado","Triangular"}, String.class); 
        assertEquals("Redondo,Cuadrado,Triangular", formas); 

 public enum MiEnum { 
            UNO, 
            DOS, 
            TRES 
        } 

MiEnum miEnum = conversionService.convert("DOS", MiEnum.class); 
        assertEquals(miEnum, MiEnum.DOS); 

public class Usuario { 
        [accesseurs] 
           private String nom; 
           private String apellido; 
        } 

public class StringToUsuarioConverter implements 
        Converter<String, Usuario>{ 
           @Override 
           public Usuario convert(String UsuarioAsString) { 
              if (UsuarioAsString == null){ 
                 throw new 
        ConversionFailedException(TypeDescriptor.valueOf(String.class), 
                    TypeDescriptor.valueOf(String.class), 
        UsuarioAsString, null); 
              } 
              String[] tempArray = UsuarioAsString.split(","); 
              Usuario article = new Usuario(Integer.parseInt 
        (tempArray[0]), tempArray[1], tempArray[2]); 
              return article; 
           } 
        } 

public class UsuarioToStringConverter implements 
              Converter<Usuario, String> { 
           @Override 
           public String convert(Usuario article) { 
         
              if (article == null) { 
                 throw new ConversionFailedException( 
                       TypeDescriptor.valueOf(Usuario.class), 
                       TypeDescriptor.valueOf(String.class), article, null); 
              } 
              StringBuilder builder = new StringBuilder(); 
              builder.append(article.getId()); 
              builder.append(","); 
              builder.append(article.getNombre()); 
              builder.append(","); 
              builder.append(article.getApellido()); 
              return builder.toString(); 
           } 
        } 

private static void testToObject(GenericConversionService 
        conversionService) { 
           conversionService.addConverter(new UsuarioToStringConverter()); 
           Usuario usuObject = new Usuario(2, "CONNOR","John"); 
           String usuAsString = conversionService.convert( 
                 new Usuario[] { usuObject }, String.class); 
           System.out.println("Usuario -->" + usuAsString); 
        } 

2. Convertir un Array en Collection y String Collection String

Es posible convertir directamente un Array en Collection y en String, como se muestra en el siguiente ejemplo:

@Log 
        public class LasConversiones2 { 
           public static void main(String[] args) { 
              GenericConversionService conversionService = 
        ConversionServiceFactory.createDefaultConversionService(); 
              testToCollection(conversionService); 
              testToString(conversionService); 
              testToObject(conversionService); 
           } 
         
           private static void testToCollection (GenericConversionService 
        conversionService){ 
              @SuppressWarnings("unchecked") 
              List<String> listOfTerm = conversionService.convert( 
                 new String[]{"t100","t800","tx"}, List.class); 
              for (String term : listOfTerm){ 
                 System.out.println("Terminator is " + term); 
              } 
           } 
         
           private static void testToString(GenericConversionService  
        conversionService){ 
         
              String terms = conversionService.convert( 
                 new String[]{"t100","t800","tx"}, String.class); 
              System.out.println("Terminator is " + terms); 
           } 
         
           private static void testToObject(GenericConversionService  
        conversionService){ 
         
              conversionService.addConverter(new  
        StringToUsuarioConverter()); 
         
              Usuario usuario = conversionService.convert( 
                 new String[]{"5,John,REESE"}, Usuario.class); 
              System.out.println("El nombre es " + usuario.getNombre()); 
              System.out.println("El apellido es " + usuario.getApellido()); 
           } 
        } Built In For Collection Type Test 

3. Converter Factory Factory

También podemos utilizar factories que nos devolverán conversores.

public class StringToUsuarioConverterFactory implements 
              ConverterFactory<String, Usuario> { 
           @SuppressWarnings("unchecked") 
           @Override 
           public <T extends Usuario> Converter<String, T>  
        getConverter( 
                 Class<T> arg0) { 
              return (Converter<String, T>) new  
        StringToUsuarioConverter(); 
           } 

public class UsuarioToStringConverterFactory implements 
              ConverterFactory<Usuario, String> { 
           @Override 
           public <T extends String> Converter<Usuario, T>  
        getConverter( 
                 Class<T> arg0) { 
              return (Converter<Usuario, T>) new  
        UsuarioToStringConverter(); 
           } 

public class LasConversionesConFactories { 
           public static void main(String[] args) { 
              GenericConversionService conversionService = new  
        GenericConversionService(); 
              conversionService 
                    .addConverterFactory(new  
        UsuarioToStringConverterFactory()); 
              conversionService 
                    .addConverterFactory(new  
        StringToUsuarioConverterFactory()); 
              String usuarioAsString = "7,Sarah,CONNOR"; 
              Usuario usuario =  
        conversionService.convert(usuarioAsString,  
                    Usuario.class); 
         
              System.out.println("El nombre es " + usuario.getNombre()); 
              System.out.println("El apellido es " + usuario.getApellido()); 
              usuarioAsString =  
        conversionService.convert(usuario, String.class); 
              System.out.println("Se utiliza como cadena [" + 
        usuarioAsString + "]"); 
           } 

4. Los formateadores predeterminados

Hay una variedad de formateadores disponibles de forma nativa en Spring.

El siguiente ejemplo ilustra cómo se utilizan.

@Log 
        public class LasConversionesFormateadores { 
           public static void main(String[] args) throws Exception { 
              testDateFormatter(); 
              testNumberFormatter(); 
           } 
           private static void testDateFormatter() { 
              Formatter dateFormatter = new DateFormatter(); 
              String dateAsString = dateFormatter.print(new Date(),  
        Locale.SPAIN); 
              System.out.println("Fecha en España: " + dateAsString); 
           } 
           private static void testNumberFormatter() throws Exception { 
              NumberFormatter doubleFormatter = new NumberFormatter(); 
              doubleFormatter.setPattern("#####.###"); 
              String number = doubleFormatter.print(new Double(12345.6789d), 
                    Locale.SPAIN); 
              System.out.println("Número: " + number); 
           } 

5. Formateadores personalizados Formateador

Podemos fabricar formateadores personalizados. Como ejemplo, vamos a utilizar el formateador de números de tarjetas de crédito. Este ejemplo es bastante común, pero ilustra las posibilidades de formato.

@Data 
        @AllArgsConstructor 
        @NoArgsConstructor 
        public class TarjetaDeCredito { 
           private int primeraTupla; 
           private int segundaTupla; 
           private int terceraTupla; 
           private int cuartaTupla; 
        } 

public class TarjetaDeCreditoParser implements Parser { 
           @Override 
           public TarjetaDeCredito parse(String cc, Locale locale) 
                 throws ParseException { 
              String caracteres[] = cc.split("-"); 
              if (caracteres == null || caracteres.length != 4) { 
                 throw new org.springframework.expression.ParseException(-1, 
                       "Invalid format"); 
              } 
              TarjetaDeCredito c = new TarjetaDeCredito(); 
              c.setPrimeraTupla(Integer.parseInt(caracteres[0])); 
              c.setSegundaTupla(Integer.parseInt(caracteres[1])); 
              c.setTerceraTupla(Integer.parseInt(caracteres[2])); 
              c.setCuartaTupla(Integer.parseInt(caracteres[3])); 
              return c; 
           } 
        } 

public class TarjetaDeCreditoPrinter implements Printer { 
         
           @Override 
           public String print(Object cc, Locale locale) { 
              TarjetaDeCredito objet=(TarjetaDeCredito)cc; 
         
              return objet.toString(); 
           } 
        } 

public class TarjetaDeCreditoFormatter implements Formatter { 
           private Parser parser; 
           private Printer printer; 
           public TarjetaDeCreditoFormatter(Parser parser, Printer printer) 
        { 
              this.parser = parser; 
              this.printer = printer; 
           } 
           @Override 
           public TarjetaDeCredito parse(String cc, Locale l) 
                 throws ParseException { 
              return (TarjetaDeCredito) parser.parse(cc, l); 
           } 
           @Override 
           public String print(Object cc, Locale l) { 
              return printer.print(cc, l); 
           } 
        } 

@Log 
        public class LasConversionesFormateadoresEx2 { 
           public static void main(String[] args) { 
              FormattingConversionService service = new  
        FormattingConversionService(); 
              TarjetaDeCreditoParser parser = new TarjetaDeCreditoParser(); 
              TarjetaDeCreditoPrinter printer = new TarjetaDeCreditoPrinter(); 
              service.addFormatterForFieldType(TarjetaDeCredito.class,  
        printer, parser); 
              test1(service); 
              test2(service); 
           } 
         
           private static void test1(FormattingConversionService service) 
        { 
              String cc = "1111-2222-3333-4444"; 
              TarjetaDeCredito o = (TarjetaDeCredito) service.convert( 
                    cc, TarjetaDeCredito.class); 
              log.info(o.toString()); 
           } 
         
           private static void test2(FormattingConversionService service) 
        { 
              TarjetaDeCredito o = new TarjetaDeCredito(1111, 2222, 3333, 4444); 
              String cc = service.convert(o, String.class); 
              log.info("El número de la tarjeta de crédito es:" + cc); 
           } 
        } 

1. Clase LosBeanWrappers

En este ejemplo se muestran las posibilidades de la clase BeanWrapperImpl:

@Log 
        public class LosBeanWrappers { 
           public static void main(String[] args) {  
              //Utilización del BeanWrapper 
              Usuario usuario = new Usuario(); 
                BeanWrapper bw = new BeanWrapperImpl(usuario); 
                bw.setPropertyValue("nombre", "John"); 
                bw.setPropertyValue("apellido", "DOE"); 
                bw.setPropertyValue("id", "200"); 
                final int id=200; 
                log.info("Verificación:"+(id==usuario.getId())+  
        "Usuario="+usuario); 
                try { 
                    bw.setPropertyValue("id", "no es numérico"); 
                } catch (TypeMismatchException e) { 
                   log.info("Err binding :"+e.getMessage()); 
                }  
         
                //Un poco más complejo 
                log.info("MutablePropertyValues:"); 
                MutablePropertyValues values = new MutablePropertyValues(); 
                values.addPropertyValue("nombre", "DOE"); 
                values.addPropertyValue("apellido", "Jane"); 
                //values.addPropertyValue("id", "2100"); 
                DataBinder dataBinder = new DataBinder(usuario, "John"); 
                dataBinder.setAllowedFields(new String [] {"nombre", "apellido"}); 
                dataBinder.setValidator(new UsuarioValidator()); 
                dataBinder.bind(values); 
                dataBinder.validate(); 
                log.info("allErrors:"); 
                List<ObjectError> allErrors =  
        dataBinder.getBindingResult().getAllErrors(); 
                for (Object object : allErrors) { 
                    ObjectError error = (ObjectError) object; 
                    log.info(error.toString()); 
                } 
         
           } 

2. Clase UsuarioValidador Validador

Los validadores se utilizan para comprobar la validez de los datos.

public class UsuarioValidador implements Validator { 
            public boolean supports(Class clazz) { 
                return Usuario.class.equals(clazz); 
            } 
            public void validate(Object obj, Errors e) { 
                ValidationUtils.rejectIfEmpty(e, "nombre", "nombre.vacio"); 
                Usuario p = (Usuario) obj; 
                if (p.getNombre().contains("s")) { 
                    e.rejectValue("nombre", "contiene.s"); 
                } else if (p.getId() < 0) { 
                    e.rejectValue("id", "id.neg"); 
                } 
            } 

1. Habilitar el soporte

La librería AspectJ aspectjweaver.jar debe estar en el classpath.

<dependency> 
           <groupId>aopalliance</groupId> 
           <artifactId>aopalliance</artifactId> 
           <version>1.0</version> 
        </dependency> 
        <dependency> 
           <groupId>org.aspectj</groupId> 
           <artifactId>aspectjweaver</artifactId> 
           <version>1.9.9.1</version> 
        </dependency> 

2. Habilitación de @AspectJ con configuración XML XML

Para habilitar el soporte AspectJ con una configuración basada en XML, se debe utilizar el elemento AOP aspectj-autoproxy.

Añada este elemento en la configuración y verifique que existe la definición del AOP:

<beans default-lazy-init="true" 
        xmlns="http://www.springframework.org/schema/beans" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:context="http://www.springframework.org/schema/context" 
        xmlns:jdbc="http://www.springframework.org/schema/jdbc"  
           xmlns:aop="http://www.springframework.org/schema/aop" 
           xsi:schemaLocation=" 
                 http://www.springframework.org/schema/beans 
        http://www.springframework.org/schema/beans/spring-beans-4.1.xsd 
                 http://www.springframework.org/schema/jdbc 
        http://www.springframework.org/schema/jdbc/spring-jdbc-4.1.xsd 
                 http://www.springframework.org/schema/context 
        http://www.springframework.org/schema/context/spring-context-4.1.xsd 
                 http://www.springframework.org/schema/aop 
        http://www.springframework.org/schema/aop/spring-aop.xsd">  
           <aop:aspectj-autoproxy/> 
           <import resource="classpath*:spring/applicationContext.xml" /> 
           <context:component-scan base-package="fr.eni.editions" /> 
        </beans> 

3. Habilitar @AspectJ con configuración Java

Para habilitar el soporte de la gestión de los componentes marcados de la anotación @Aspect de AspectJ, hay que utilizar la anotación @Enable-AspectJAutoProxy.

Por ejemplo:

@Configuration 
         @EnableAspectJAutoProxy 
         public class AppConfig { 
         
             @Bean 
             public FooService fooService() { 
                 return new FooService(); 
             } 
         
             @Bean 
             public MyAspect myAspect() { 
                 return new MyAspect(); 
             } 
         } 

4. Declaración de un aspecto

Una vez que se ha activado @AspectJ, Spring AOP detecta automáticamente todas las clases orientadas a aspectos. Es posible declarar el aspecto para una clase mediante una anotación @Aspect (org.aspectj.lang.annotation.Aspect) o en el archivo XML.

No se aborda la declaración de aspectos en el archivo de configuración XML porque se sustituye ampliamente por anotaciones. Por defecto, el bean correspondiente a la clase orientada a aspectos es un singleton. El objeto puede contener métodos y variables, así como pointscuts, advices y declaraciones intertypes. 

Las clases anotadas con @Aspect pueden tener métodos y campos como el resto de las clases, pero no es posible orientar a aspectos un aspecto. Esto puede ayudar a contrarrestar los intentos de orientar a aspectos las clases críticas.

5. Declaración de un pointcut Pointcut

Spring permite interceptar un conjunto de métodos a partir de su nombre mediante la detección de puntos en común en la tipología de sus firmas.

@Pointcut("execution(* voir*(..))") 
        public void aspectjLoadTimeWeavingExamples() { 

El pointcut se llama antes del método interceptado y puede modificar, y a continuación devolver, el objeto devuelto por el método interceptado.

Los siguientes verbos indican el tipo de corte:

También es posible limitar los candidatos con criterios:

Solo los métodos públicos pueden ser interceptados. Los métodos private y protected no se tienen en cuenta para los aspectos.

Es posible combinar puntos de unión mediante el uso de operadores && (y), || (o), así como ! (negación).

@Pointcut("execution(* escuchar*(..))") 
        public void aspectjLoadTimeWeavingExamples2() { 

Ejecución de todos los métodos públicos:

execution(public * *(..)) 

Ejecución de todos los métodos que comienzan con set:

execution(* set*(..)) 

Ejecución de todos los métodos definidos en la interfaz ClientService:

execution(* com.eni.ClientService.*(..)) 

Ejecución de todos los métodos que están en un paquete determinado:

execution(* com.eni.*.*(..)) 

Ejecución de todos los métodos que están en un paquete o subpaquete determinado:

execution(* com.eni..*.*(..)) 

Todos los puntos de acción que se encuentran en el paquete service:

within(com.eni.service.*) 

Todos los puntos de acción que se encuentran en el paquete service y sus subpaquetes:

within(com.eni.service..*) 

6. Declaración de graft sencillos Graft

Para los graft sencillos, es posible utilizar las siguientes anotaciones:

@Before se utiliza, por ejemplo, si busca la palabra «iniciar» en la firma para ejecutar un proceso antes de llamar al método.

En una turbina:

@Before("execution(* 
        fr.eni.editions.beans.Barco.iniciarTurbina(..))") 
        public void verificarCombustibleTurbina() { 
           final Logger logger = 
        LoggerFactory.getLogger(VerificarAntes.class); 
           logger.info("antes de arrancar la turbina"); 

En todos los medios de propulsión:

@Before("execution(* iniciar*(..)) ") 
        public void verificarCombustible() { 
        System.out.println("justo antes de arrancar"); 
        } 

Por ejemplo, @After se utiliza si busca la palabra «iniciar» en la firma para ejecutar un proceso después de la llamada al método.

En todos los medios de propulsión:

@After("execution(* iniciar*(..))") 
        public void verificarVelocidad() { 
           System.out.println("Después del arranque"); 
        } 

También es posible retornar el valor devuelto del método interceptado:

@After("execution(* iniciar*(..))") 
        public Object verificarCombustible(Object retVal)  { 
            System.out.println("justo después de arrancar"); 
             return (retVal); 
        } 

@AfterThrowing se utiliza para tener un procesamiento después de una excepción. 

@Aspect 
        public class AfterThrowingExample { 
           @AfterThrowing("fr.eni.MiExcepcion()") 
              public void doRecoveryActions() { 
               // ... 
           } 
        } 

Es posible recuperar el tipo de la excepción para explotarlo:

@Aspect 
        public class AfterThrowingExample2 { 
           @AfterThrowing( 
              pointcut="fr.eni.MiExcepcion()",throwing="ex") 
              public void doRecoveryActions(DataAccessException ex) { 
                    // ... 
           } 
        } 

@After se utiliza para tener código después del finally.

@Aspect 
        public class AfterFinallyExample { 
        @After("fr.eni.MiExcepcion()") 
           public void doReleaseLock() { 
                    // ... 
           } 
        } 

@Around intercepta completamente una llamada de método.

El método de interceptación tiene acceso a los argumentos de la llamada del método interceptado.

@Around("execution(* iniciar*(..))") 
        public Object generico(ProceedingJoinPoint joinPoint) throws 
        Throwable { 
           final Logger logger =  
        LoggerFactory.getLogger(joinPoint.getSignature().getDeclaringType()); 
           logger.info("Interception iniciar:"); 
           logger.info("method : " + joinPoint.getSignature().getName()); 
           logger.info("arguments : " + Arrays.toString(joinPoint.getArgs())); 
           logger.info("Around before is running!"); 
           Object ret = joinPoint.proceed(); 
           logger.info("Around after is running!"); 
           logger.info("Return " + ret.toString()); 
           return ret; 

7. Tipos genéricos Tipos:genéricos

Spring AOP admite tipos genéricos. Es posible que queramos interceptar solo ciertos tipos. En este caso, filtramos por dichos tipos.

Por ejemplo, para filtrar solo sobre MyType para la siguiente interfaz:

interface Sample<T> { 
            void sampleGenericMethod(T param); 
            void sampleGenericCollectionMethod(Collection<T> param); 

Filtramos por tipo:

@Before("execution(* ..Sample+.sampleGenericMethod(*)) && 
        args(param)") 
        public void beforeSampleMethod(MyType param) {  
            // Advice implementation 

Para las colecciones genéricas, es más complicado. No es posible hacer este tipo de código:

@Before("execution(* ..Sample+.sampleGenericCollectionMethod(*)) 
        && args(param)") 
        public void beforeSampleMethod(Collection<MyType> param) { 
            // Advice implementation 

Es necesario evitarlo de la siguiente manera:

@Before("execution(* ..Sample+.sampleGenericCollectionMethod(*)) 
        && args(param)") 
        public void beforeSampleMethod2(Collection<?> param) { 
            // Advice implementation 

y validar para cada tipo si nos desviamos o no.

8. Determinación de nombres de argumentos

Antes de Java 8, no era posible simplemente recuperar el nombre de los argumentos de un método. Spring AOP, que sigue siendo compatible con Java 7 (y versiones superiores), utiliza estrategias para determinar los nombres de los argumentos. La forma más fácil es tener el mismo número y orden para los argumentos entre el método interceptado y el método de interceptación.

9. Orden de llamada de los grafts que interceptan el punto de unión

Los grafts se pueden llamar uno tras otro y es posible determinar un orden de paso preferente.

Es suficiente con agregar la interfaz org.springframework.core.Ordered a la clase del aspecto o añadir la anotación @Order y codificar el método getOrder():

public int getOrder() { 
         return 0; 

La clase que devuelve el orden más alto se ejecuta en primer lugar.

10. Inyección

Es posible agregar dinámicamente métodos y sus implementaciones a las clases (declaraciones intertypes con AspectJ).

Para hacer esto, creamos una clase de aspectos y añadimos la declaración del método a través de la anotación @DeclareParents. A continuación, se agrega un aspecto que indica cuándo llamar a este método.

Ejemplo:

@Component 
        @Aspect 
        public class LinkAspects {  
          @DeclareParents(value="fr.eni.spring5.TrucAdditionalDetailsImpl+", 
        defaultImpl=Truc.class) 
          public static TrucImpl trucImpl; 
        } 

11. El mecanismo de los proxys Proxy

Spring AOP utiliza proxys dinámicos del JDK para los objetos que exponen las interfaces que hay que intervenir. De lo contrario, Spring usa CGLIB.

Los métodos finales no se pueden intervenir.

Se llama al constructor del objeto convertido en proxy dos veces: una vez para el proxy y una segunda vez para el advice.

Para forzar el uso de un proxy CGLIB, debe pasar por la configuración XML:

   <aop:config proxy-target-class="true"> 
            <!-- other beans defined here... --> 
           </aop:config> 

Si utiliza la anotación @AspectJ, es suficiente con especificar en el archivo XML:

<aop:aspectj-autoproxy proxy-target-class="true"/> 

Las secciones <aop:config/> de los archivos de configuración XML se combinan en la memoria. Por lo tanto, el uso de CGLIB es común para:

Por lo tanto, la decisión de activar los CGLIB debe estar bien pensada porque puede haber efectos secundarios.

12. El lado oculto de los proxys en AOP

Es posible crear aspectos en el código, que se añaden a los declarados a través de la configuración <aop:config> o <aop:aspectj-autoproxy> complementado con anotaciones dedicadas.

Se pueden utilizar API Java simples:

package fr.eni.editions; 
        import java.lang.reflect.Method; 
        import org.springframework.aop.AfterReturningAdvice; 
        import org.springframework.aop.aspectj.annotation.AspectJProxyFactory; 
        interface Pojo { 
            public void foo(); 
            public void bar(); 
        class SimplePojo implements Pojo { 
            public void foo() { 
                System.out.println("foo"); 
                this.bar(); 
            } 
            public void bar() { 
                System.out.println("bar"); 
            } 
        class UsageTracker implements AfterReturningAdvice { 
           public void afterReturning(Object returnValue, Method method, 
                Object[] args, Object target) throws Throwable { 
              System.out.println("after "+method.getName()); 
           } 
        public class Main2 { 
           public static void main(String[] args) { 
              AspectJProxyFactory factory = new AspectJProxyFactory(new 
        SimplePojo2()); 
              factory.addAspect(SecurityManager.class); 
        //  factory.addAspect(new UsageTracker()); 
              Pojo pojo = (Pojo) factory.getProxy(); 
           } 

Esta forma de programar resalta más fácilmente ciertos efectos secundarios relacionados con AOP y los proxys.

Normalmente, si tenemos un objeto clásico sin orientación a aspectos como este y llamamos a un método en una referencia de este objeto, llamamos directamente al código del método:

interface Pojo4 { 
            public void foo(); 
            public void bar(); 
        class MiSencilloPojo implements Pojo4 { 
            public void foo() { 
              System.out.println("foo"); 
                this.bar(); 
            } 
            public void bar() { 
              System.out.println("bar"); 
            } 
        public class Main3 { 
            public static void main(String[] args) { 
                Pojo4 pojo = new MiSencilloPojo(); 
                // this is a direct method call on the pojo reference 
                pojo.foo(); 
            } 

Se obtiene:

foo 
        bar 

Pero si añadimos algo como esto: