En esta oportunidad les escribo sobre un nuevo namespace que apareció en Spring 3.1 (y me dí cuenta recién XD ) y sirve para configurar los beans haciendo uso de su constructor. Como su nombre lo indica este es un namespace que opera sólo sobre los constructores de beans y así permitir la inyección de beans o valores.
Les dejo una imagen de como se activa este nuevo namespace en el STS.
Veamos un ejemplo simple de cómo usar namespace C.
<!-- Definición del datasource de ejemplo --> <beanid="datasource"class="com.mchange.v2.c3p0.ComboPooledDataSource"> ... ... </bean>
Como pueden notar en el ejemplo, el namespace C permite configurar los constructores de los beans y tiene dos formas básicas, por valor y referencia. Para inyectar una instancia preconfigurada se debe usar el sufijo -ref para hacer alusión a que es una referencia. Si se desea inyectar un valor, sólo se usa el nombre del argumento del constructor.
Una manera sencilla de crear Proxy es usando SpringFramework, siempre y cuando tengas configurado tu aplicación con Spring, de otra forma, puedes buscar otras librerías que puedan ayudarte con el patrón Proxy (dinámico), (cglib y javassist) o puedes utilizar la API de java para crearlos. Revisa aquí Java Dynamic Proxy o Patrones De Diseño: Proxy.
Por ahora voy a mostrar como configurar un Proxy Dinámico con SprinFramework, configuraciones y par un de conceptos.
Conceptos
Target: Es la clase que será envuelta por el proxy (RealSubject)
Interceptor(es): Son las clases accesorias donde deberás agregar la lógica de negocio asociada al Proxy. Estos interceptores pueden ser mas de uno para un mismo target.
ProxyFactoryBean: Es la clase de Spring Framework para crear proxys dinámicos, al estilo Spring (con un FactoryBean). Deja un bean configurado dentro del contexto, listo para ser usado. Lo bueno de esta estrategia es que la creación del Proxy se realiza sólo una vez y cuando levanta el contexto, al contrario del Proxy que provee la API de Java, por cada invocación se debe crear el Proxy (aunque es rápido pero todo suma).
Interceptores
Los interceptores son clases que contienen la lógica de negocio del Proxy, es el símil a el InvocationHandler de la API de Java. Estas clases deben ser implementadas desde la interfaz Interceptor que es la de mas alta jerarquía o de su herencia, MethodInterceptor o ConstructorInterceptor. Estas últimas clases pertenecen a la librería de aopalliance versión 1.0 en el package org.aopalliance.intercept.
Para poder agregar las 2 funcionalidades (loggear los parámetros de entrada y validar que no sean negativos), implementaremos 2 Interceptores con la finalidad de aislar las lógicas de negocio de cada uno.
calculadora: Es la clase a envolver en el Proxy (RealSubject o target).
calculadoraWithProxy: Proxy Factory que crea el bean configurado como Proxy. En este bean deben fijarse en las propiedades configuradas:
target: Es una referencia al bean con id calculadora.
interceptorNames: Es una lista con los id de los beans que harán de interceptores. En este caso son dos los interceptores validate y logger.
Notas
Como podrán ver, usé las mismas clases del post Java Dynamic Proxy y sólo agregue los Interceptores donde se concentra la lógica de negocio solicitada.
Recuerden que como se trata de un Proxy Dinámico se necesita que CalculadoraImpl implemente una interfaz conocida, en este caso, Calculadora.
La clase ProxyFactoryBean posee varios atributos mas que permiten agregarle funcionalidad y configuraciones al proxy, échenle un vistazo.
Test Unitario
Para poder probar las funcionalidades realicé el siguiente test unitario:
------------------------------------------------------- T E S T S ------------------------------------------------------- Running patterns.proxyAOP.CalculadoraServiceAOPTest ---------------------------------- Argument 1 Argument 2 ---------------------------------- Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.592 sec
Mediante esta interfaz puedes inyectar el servletContext a la configuración de tu Bean, siempre y cuando tengas un contexto web funcionando.
He aquí el segundo problema, ¿ Cómo puedo tener el un contexto web dentro de un Junit ?. Puede que exista una mejor forma de hacerlo pero lo logré de la siguiente manera.
Buscando por todos lados encontré que a mi test unitario le faltaba un par de configuraciones para la lectura del contexto Spring.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = { "/test/test-context.xml" } @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class }) public class ReadFileFromWebinfTest { @Autowired private ReadFileFromWebinf _readFileFromWebinf; public void testReadFile(){ String fileContent = _readFileFromWebinf.load("archivo.xml"); System.out.println(fileContent); } }
Las dos primeras anotaciones son para decirle a Spring que se va a utilizar Junit para ejecutar la clase y cual o cuales son los contextos a cargar.
Luego viene la anotación que me arregló el día, TestExecutionListeners y el listener asociado para la completar las inyecciones de dependencia de todos los beans. (Antes con Autowired solo hacía algunos).
Esta interfaz de Spring Framework te permite una vez configurado el contexto, ejecutar el método afterPropertiesSet(), y como su nombre lo dice, lo ejecuta luego de ejecutar los métodos setter del bean (post configurar el bean).
1 2 3 4 5
publicinterfaceInitializingBean {
voidafterPropertiesSet()throws Exception;
}
Algunas aplicaciones de esta interfaz:
Validar que los atributos de un Bean estén correctamente inicializados.
A partir de los atributos ya setteados, generar otra propiedad en tiempo de configuración. Por ejemplo, se configura el bean con dos atributos de tipo int y en tiempo de configuración quiero calcular la suma de ambos y dejarlo en otra propiedad. ¿ Qué gano con esto ? que esa propiedad no se calcula cada vez que hago el getter sino que ya esta previamente calculada.
Para el primer caso, recomiendo utilizar la clase Assert ya que provee métodos con los que puedes invalidar que el contexto Spring levante si hay errores en la configuración.
Les dejo un código de ejemplo para que le echen un vistazo (le agregué la interfaz al ejemplo del post anterior)
Voy a explicar un poco y a groso modo el como funciona esta clase desde el punto de vista de Spring:
Se lee la configuración asociada a la clase ExampleBean
Se crea la instancia de la clase ExampleBean
Luego vía inyección se le settean los atributos, entre ellos randomValue
Luego de la creación del bean ExampleBean se ejecuta el método afterPropertiesSet(), en donde se realiza una validación del randomValue (este NO puede ser nulo, de serlo, el contexto de Spring no quedara operativo), si eso pasa OK, se calculará el atributo newValue y que será randomValue multipliado por 10.
Finalmente y si no hay errores en el contexto de Spring, se deja la instancia del bean ExampleBean en el contexto, es decir, el valor randomValue y newValue quedan listos para ser usados.
Este proceso se realiza sólo una vez (salvo que el scope no sea singleton) y es en el momento de la creación del contexto.
Demás esta decir que esta clase/bean (ExampleBean) debe estar configurada en el archivo del contexto de Spring o vía las anotaciones (metadata) provistas para eso.
En este post voy a tratar de explicar porque FactoryBean es increíblemente útil para alambrar (aplicar DI) aplicaciones hechas con Spring Framework.
La interfaz de FactoryBean dice lo siguiente:
1 2 3 4 5 6 7 8
publicinterfaceFactoryBean<T> {
T getObject()throws Exception;
Class getObjectType();
booleanisSingleton(); }
La utilidad de la implementación de esta interfaz y su posterior declaración como Bean dentro del contexto de la aplicación, es que puede ser usada (como su nombre lo indica) como Factory para inyectar algún valor en alguna propiedad de otro Bean.
¿Dónde y cómo funciona? Dentro del ciclo de vida de la carga del Contexto de spring, la ejecución de la implementación de esta interfaz, esta justo antes de hacer los setters de las propiedades de un Bean. El funcionamiento es simple, siempre se ejecutará el método getObject() que retornará la instancia del tipo T.
Veamos una implementación simple y una configuración de contexto de spring:
public Integer getObject()throws Exception { return Integer.valueOf(newRandom().nextInt()); }
public Class getObjectType() { return Integer.class; }
publicbooleanisSingleton() { returntrue; }
}
Esta simple implementación de FactoryBean retorna un Integer en el método getObject(), simplemente eso (obviamente en este método debes poner todo tu talento para resolver el valor que andas buscando, esto es un ejemplo simple).
El método getObjectType() es usado internamente por el framework para validar que el retorno de getObject() sea correcto o que este dentro de la jerarquía de clases, esto es en caso de que quieras restringir por tipo.
El último método isSingleton() es si quieres que esta clase (no importa la cantidad de declaraciones que tengas, siempre será la misma), es un tanto dificil de entender pero les sugiero que lean sobre el concepto de Singleton que tiene SpringFramework. En el ejemplo de configuración espero que les quede claro, de lo contrario, bienvenidas las preguntas.
Esta es la definición del Bean de ejemplo, en donde se hará uso del FactoryBean:
Se declara el Bean exampleBean1 y que tiene como propiedad el atributo randomValue y cuyo valor será producto de la ejecución del Bean RandomNumberFactoryBean en el momento que el contexto de Spring es cargado. En este caso se utiliza la técnica de InnerBean, es decir, no se tiene una instancia del Bean para ser reutilizada sino que esta en la misma declaración del setter del atributo.
Ejemplo 2:
Este ejemplo hace lo mismo indicado arriba, sólo que no se aplica InnerBean sino que se extrae y es reutilizado en el bean exampleBean21 y exampleBean22. En este ejemplo entra en juego el método isSingleton(), si es true, quiere decir que el valor que entregará el FactoryBean siempre será el mismo para ambos Beans. Ahora bien, si se cambia a false, por cada setter, es decir, para exampleBean21 y exampleBean22 se realizara la ejecución de RandomNumberFactoryBean 2 veces. (En este caso, nos entregará dos valores aleatorios para cada bean)
En pocas palabras para cada Bean del ejemplo 2 habrá dos instancias de RandomNumberFactoryBean que entregará cada una un Integer para los atributos de los beans declarados.
Algo interesante de las implementaciones de FactoryBean es que luego de la carga del contexto, estas instancias son desechadas.
Espero les sea útil y cualquier pregunta sera bienvenida.