Título: CDI 1.1 - Context and Dependecy Injection Publicado por: Usuario Invitado en 15 Julio 2015, 03:56 am CDI Context and Dependency Injection o Contexto e inyección de depencias en español, es un poderoso elemento de la plataforma Java EE el cual nos provee un poderoso mecanismo de inyección de depencias. Además, nos provee de muchas utilidades, como interceptores, calificadores, eventos, decoradores, productores y trituradores, entre otros. CDI es un concepto incomprendido por gran parte de los programadores Java EE. En el presente documento, intentaremos despejarnos las dudas. Empecemos. Dependency Injection Dependency Injection (DI) es un patrón de diseño que desacopla componentes depenientes. Es parte de inversion of control (IoC) donde el objetivo que es invertido es el proceso de obtención de dependencias necesarias. El término fue originalmente dicho por Martin Fowler. Una manera de pensar en DI en un entorno manejado como Java EE es pensar en JNDI al revés. En lugar que un objeto busque por otros, el contenedor inyecta su dependencia por ti. Esto es llamado Principio Hollywood, "Don't call us (buscar objetos), we'll call you (inyectar objetos)". Gestión del ciclo de vida El ciclo de vid de un POJO es muy simple, creas una instancia de una clase usando la palabra reservada new y esperas a la recolección de basura para que la elimine y libere algo de memoria. En su lugar, necesitas inyectar el bean y el contenedor hace el resto, esto quiere decir que el contenedor es el único responsable de gestionar el ciclo de vida de un bean: este lo crea, este lo destruye. Así que, ¿como inicializas un bean si tu no llamas a un constructor? El contenedor te brinda un manejo luego de construir la instancia y antes de destruirla. Estas anotaciones son:
CDI Bean Un bean CDI puede ser cualquier tipo de clase que contenga lógica de negocio. Este puede ser llamado directamente por código Java vía inyección o puede ser invocado vía El desde una página JSF. Un bean es un POJO que no extiende de nada, puede inyectar referencias en otros beans (@Inject), tiene su ciclo de vida manejado por el contenedor y puede tener sus propios metodos incerptores: Código
En el ejemplo anterior, se está inyectando la dependencia del bean accountChecker, esto lo hace el contenedor. El método initializeDate anotado con @PostConstruct será llamado automáticamente luego de que se instancie la clase BankLoan. Los CDI beans tienen ciertas características que deben cumplirse de manera obligatoria. Estas son:
Para mayor comprensión, veamos el siguiente diagrama de clases: (http://i.imgur.com/MH5jAck.png) ¿Cómo conectamos CDStore y CreditCard? La forma que todos conocemos es mediante el operador new: Código
El código anterior es bien simple y es lo que nosotros hacemos y conocemos. Pero, ¿que pasaría si quisieras pagar con MasterCard?, ¿Necesitarías crear una (otra) instancia de MasterCard? Una solución pasar su dependencia por medio del constructor de una clase externa que haga uso de la clase CDStore: Código
En otra clase: Código
Ésto es lo que se conoce como inversion of control (IoC) o inversión de control (en español). La dependencia se inyecta desde una tercera clase, de ésta manera no creamos un vínculo entre CDStore y CreditCard. Inyección (@Inject) Java EE es un entorno gestionado, así que quizás no necesitas construir las dependencias tú mismo, en su lugar, puedes dejar que el contenedor inyecte las dependencias de los beans por tí. CDI tiene la habilidad de inyectar dependencias de prácticamente lo que sea. Veamos un ejemplo: Código
Como se puede observar, no necesitamos construir la dependencia de creditCard, se lo dejamos al contenedor. La implementación se vería así: Código
Nota que solo hemos especificado una implementación de la interface CreditCard. Si hubiéramos creado otra implementación, la inyección no se podría realizar porque el contenedor no sabría qué dependencia inyectar. Esto, lo resolveremos más adelante con calificadores (@Qualifier). ANEXO Puntos de inyección Una inyección puede llevarse a cabo en tres puntos:
Código
Nota que no es necesario especificar setter para la propiedad.
Código
La regla aquí es que la inyección por constructor se puede realizar solo una vez (por clase).
Código
Ésto es un anexo, porque en realidad no importa en qué punto hagas la inyección. Por propiedad, constructor o setter, para el contenedor le da igual. Por lo tanto, escoger uno u otro, es simplemente opción personal. Injección por defecto (@Default) Tu puedes tener una dependencia para inyectar por defecto. Por ejemplo, nosotros tenemos solo una implementación, aquella, tendrá implícitamente el modificador @Default. Así, ésto: Código
Es igual que: Código
Podemos apreciarlo en una imagen: (http://i.imgur.com/EeiTU4I.png) Si tienes una implementación, el contenedor inyectará la única dependencia existente. Si por otro lado, tienes muchas implementaciones de una interface, el contenedor no sabrá cuál implementación debe inyectar, y aquí es cuando toman tanta importancia los calificadores. Calificadores (@Qualifier) Cuando el sistema inicia, el contenedor CDI debe validar que todos los beans satisfasgan cada punto de inyección existente. Si alguna dependencia de un bean no puede ser satisfecha por el contenedor CDI, entonces la aplicación no se podrá desplegar informando de una insatisfacción de dependencia. Si hay una sola implementación disponible, la inyección funcionará aplicando la dependencia única, que es marcada implícitamente con @Default. Si hay más de usa implementación y tratamos de desplegar, la aplicación no desplegará porque dectectará ambiguación en las dependencias, es decir, si hay 2 o más implementaciones, ¿cómo sabe el contenedor qué dependencia inyectar? Aquí es donde toman importancia los calificadores. Veamos el siguiente diagrama de clases que ilustra la situación actual: (http://i.imgur.com/c3tTF8v.png) Podemos ver que hemos creado una nueva implementación, llamada MasterCard, la misma está anotada bajo el calificador MasterCardPay. Además, vemos como una nueva clase, CDStoreWithQualifier inyecta la nueva dependencia. Esto lo hará mediante el calificador. Veamos el ejemplo en código (solo las nuevas clases): Calificador MasterCardPay: Código
Implementación MasterCard: Código
La anotación @Retention, especifica el nivel de retención de la anotación. Existen 3 tipos:
Las primeras dos anotaciones no podrán ser inspeccionadas en tiempo de ejecución, mientras que la última sí. Esta es la diferencia entre las 3. La anotación @Target, especifica que elementos podrán ser afectados por la anotación. Hay varias opciones:
Creo que la mayoría se explican solas. Las dos anotaciones que son un poco confusas son ANNOTATION_TYPE y TYPE. ANNOTATION_TYPE significa que la anotación solo podrá ser usada para anotar otras anotaciones, como @Retention. TYPE significa cualquier tipo de elemento (clases, interfaces, enums, anotaciones, etc). Comprendidos ya estos conceptos, vamos a ver la clase que inyecta la nueva implementación: Código
Observa lo sencillo que es inyectar múltiples dependencias, solo basta con indicar el calificador de la dependencia que debe ser inyectada. Es posible también anotar un elemento con múltiples anotaciones. Java no nos limita en este aspecto. Por ejemplo: Código
Productores (@Produces) Como ya hemos visto, podemos inyectar CDI beans dentro de otros CDI beans. Pero, si quisiéramos inyectar POJOs, o tipo de datos primitivos, ¿sería eso posible? La respuesta corta es no y la razón es la siguiente. Por defecto, no puedes inyectar clases como String o Date y la razón, es porque ellas están empaquetadas en el archivo rt.jar (Java runtime enviroment classes) y este no contiene un descriptor de beans beans.xml. Esto es importante tenerlo presente, si un archivo no tiene un descriptor beans.xml bajo el directorio META-INF, CDI no activará el descrubimiento de beans (bean discovery) y los POJOs no podrán ser tratados como beans y por ende, no podrán ser inyectados. Afortunadamente, podemos revertir esta situación con ayuda de los productores. Veamos un ejemplo: (http://i.imgur.com/EBPpcIq.png) Veamos que la clase CDSerialProducer tiene 3 anotaciones, las cuales pasamos a describir:
Primer veamos nuestras anotaciones, serán igual que los calificadores que ya hemos visto: Código
Código
Ahora, veamos como producimos beans para inyectar de tipo String e int: Código
La anotación @Produces, producirá una propiedad y un método para inyectar. Seguido de @Produces, debemos de especificar el calificador con el cual se va a inyectar la propiedad y el método. En este caso son @CDSerialPrefix y @RandomNumber. Ahora veamos como los inyectamos: Código
Si ejecutamos el proyecto, podemos ver que se inyectan satisfactoriamente los valores de la propiedad y el método dentro de las propiedades de CDService. Gracias a los productores, podemos inyectar prácticamente lo que sea. ANEXO API de InjectionPoint Los atributos y propidades producidad por productores (@Produces) no necesitan saber ningún tipo de información acerca de donde ellos son inyectados. Sin embargo, hay ciertos casos donde podría ser de utilidad que el bean a inyectar sepa en qué punto de inyección se ha llevado a cabo la inyección. Un ejemplo común de ésto, es generar una dependencia dinámica de Logger (para crear logs). Generalmente, siempre creamos un Logger así: Código
Lo anterior funciona correctamente, pero también podríamos generar depenencias dinámicamente. Veamos primero la API de InyectionPoint: (http://s2.postimg.org/yuy9wab2x/inyectionpoint_api.png) Podemos usar esta API para generar una dependencia dinámica para Logger. Veamos un ejemplo: Código
Perfecto. Ahora tan solo debemos inyectar al logger de ésta manera: Código
¿Cómo ocurre la magia? Bien, el contenedor CDI buscará cualquier bean de tipo Logger listo para inyectar, y lo encuentra gracias a que hemos anotado el método con @Produces, lo que deja ese método listo para su inyección (como con @CDSerialPrefix y @RandomNumber del ejemplo anterior). Trituradores (@Disposes) Ahora sabemos como producir beans o valores para inyectar, pero algunos beans podrían necesitar ser cerrados, como es el caso de conexiones JDBC o un EntityManager. Por lo tanto, algunos beans producidos deberían asegurarse de ser cerrados. Aquí es donde toman importancia los Disposers. Los Disposers son lo contrario a Producers, éste último crea beans o valores para inyectar, mientras que el primero se encarga de destruirlo. Veamos un ejemplo con una clásica conexión JDBC: Código
Un método disposer debe obligatoriamente recibir un parámetro @Disposes y el tipo del parámetro debe ser el mismo que el tipo devuelto con el método productor (@Produces) y su calificador (@Qualifier) en caso haya más métodos productores con el mismo tipo de retorno. Dado que el ciclo de vida de un bean inyectado depende del contexto en donde se inyecta, cuando se elimina el bean que contiene el bean inyectado, éste se destruirá también. Pero si no hubiésemos escrito el método disposer, la conexión nunca se hubiese cerrado por ser ésta independiente del contexto. Cuando el bean que contiene el bean inyectado es eliminado, antes que eso ocurra, se ejecutará el método disposer del bean inyectado, en este caso, cerrando la conexión JDBC. ANEXO Alcances (scopes) Todo objeto cuyo ciclo de vida es manejado por CDI tiene un alcance definido y un ciclo de vida que está ligado a un contexto específico. En Java, el alcance de un POJO es muy simple: tu creas una instancia de una clase usando la palabra reservada new y tu confías en el recolección de basura para deshacerse de él y liberar alguna memoria. Con CDI, un bean es ligado al contexto y este lo mantiene en ese contexto hasta que el bean es destruido por el contenedor. No hay manera para remover manualmente un bean desde un contexto. CDI define los siguientes alcances y permite puntos de extesión para crear tu propio alcance:
Como puedes ver, todos los alcances tienen una anotación que tu puedes usar en tus beans CDI (todas ellas están en el paquete javax.enterprise.context). Los primeros tres alcances son bien conocidos. Por ejemplo, si tu tienes un bean de alcance de sesión como de un carro de compras, el bean será automáticamente creado cuando la sesión inicia (primera vez que un usuario se loguea) y es destruido automáticamente cuando la sesión termina. Citar Notas: El ciclo de vida de un bean @Dependent está ligado al ciclo de vida del bean que lo contiene. Se crea cuando el bean que lo contiene es instanciado y es eliminado cuando el mismo es eliminado. Es el scope por defecto. Conversation (@ConversationScoped) El alcande conversation es un poco diferente al resto. Este alcance mantiene estados asociados en un intérvalo de tiempo, a través de múltiples peticiones y es eliminado programáticamente (explícitamente) por la aplicación. Este alcance es usado mayormente en procesos donde se requiere mantener valores durante múltiples peticiones HTTP pero sin extenderse demasiado, como un alcance @SessionScoped. API de Conversation: (http://i.imgur.com/gq3kOhq.png) La principal diferencia con otros alcances, es que ellos son eliminados automáticamente por el contenedor al cabo de un tiempo cuando termina la petición, sesión, aplicación, etc. En Conversation, nosotros debemos encargarnos terminar su ciclo de vida. Por ejemplo, un bean @ConversationScoped puede ser usado para un asistence de registro de usuario. Deseamos mantener los datos que se van registrando del usuario a través de distintas páginas y que elimine el bean al terminar el registro: Código
Para probarlo, crea distintas páginas JSF y en cada una pon un formulario con un input text para el email, un input secret para el password y un input text para la fecha de cumpleaños: start.xhtml Código
step2.xhtml Código
end.xhtml Código
Al llegar a la últma página y pulsar el botón registrar, se ejecuta el método registrar(), donde termina la conversación y se imprime toda la información del usuario recolectada durante la misma. Interceptores (@Interceptor) Los interceptores te permiten agregar conceptos a través de tus beans. Cuando un cliente invoca a un método en un Managed Bean (y por lo tanto a CDI beans, EJB, RESTful, ...), el contenedor puede interceptar la invocación y procesar lógica de negocio antes que el método del bean sea invocado. Los interceptores vienen en cuatro tipos:
Un método anotado con @AroundInvoke, debe tener el siguiete patrón de firma: Código
Las siguientes reglas aplican a un método @AroundInvoke:
Echememosle un ojo a la API de InvocationContext: (http://i.imgur.com/gq3kOhq.png) Otra forma de trabajar con interceptores, es que estos pueden estar en una clase y luego ser referenciada por la clase que los necesite: Código
O en algún método: Código
Si queremos que un método no sea interceptado, lo anotamos con @ExcludeClassInterceptors. Veamos un ejemplo: (http://i.imgur.com/VBhuZSQ.png) Vamos con nuestro interceptor: Código
Y nuestra clase que se verá afectada por nuestro inteceptor: Código
Cuando se instancie ésta clase y cuando llamemos al método login(), se ejecutarán los interceptores que hemos definido en LoginInterceptor, que son uno a nivel de método y otro a nivel de constructor. Citar También se pueden proporcionar más de un interceptor, deben separarse por comas: Código
Los interceptores serán ejecutados en el orden que son escritos. Vinculación de interceptores (@InterceptorBinding) Una manera más práctica y que es la más aconsejada por su bajo acoplamiento, es Interceptor Binding. Es muy fácil de hacer, solo basta crear un Interceptor Binding que es muy parecido a un calificador: Código
El interceptor cambia muy poco, solo debemos anotar con @Interceptor y el interceptor binding que hemos creado, en nuestro caso, @Loggable: Código
Ahora, en nuestra clase objetivo (donde se interceptarán los métodos), solo debemos anotar la clase o los métodos/constructor que queremos interceptar. Por ejemplo: Código
Como se puede observar, es mucho más práctico de esta forma y además, más agradable a la vista. Para poder utilizar ésta manera, debemos de agregar nuestro interceptor binding en el descriptor de beans (beans.xml): Código
Prioridad de interceptores Los interceptores sigue el orden en el que los hemos escrito en la clase interceptada, pero podemos crear nuestro propio orden. Por ejemplo, tenemos dos interceptores con prioridad diferente: Código
Código
Ahora, nuestra clase interceptada: Código
Si ejecutamos, veremos la siguiente salida: Código: Información: Ejecuando método interceptor checkCdDisponibility Como vemos, el primer interceptor (menor prioridad) se ejecuta primero y el segundo (mayor prioridad), se ejecuta después de éste, pero el segundo termina primero. Luego que termina el interceptor de mayor prioridad, el flujo vuelve hacia el de menor prioridad. Decoradores (@Decorator) Decorador es un patrón de diseño muy común, originalmente acuñado por Gang of Four (la banda de los cuatro). La idea detrás de este patrón es tomar una clase y envolverla con otra (se dice que esta la decora). De esta manera, cuando tu llamas a una clase decorada, debes pasar a través del decorador antes que alcances la clase objetivo. Los decoradores son usados para añadir lógica a un método. Tomemos como ejemplo un registro para una tienda de CDs online. Hay la membresía básica, que los permite acceder gratis a 15 CDs. Luego, cuando hay ofertas, viene el decorador que lo que hace es incrementar la cantidad de CDs a 40 (+25 del decorador). interface Membership Código
Implementación BasicMembership Código
@Basic es un calificador, que como ya sabemos sigue ésta anatomía: Código
Ahora, veamos nuestro decorador: Decorador MembershipGiftDecorator Código
Lo primero que vemos, es que hemos anotado el decorador con @Decorator. Esta anotación le dirá al contenedor que es decorador. Un decorador debe implementar a la interface de la implementación que quiere decorar, es por eso que el decorador implementa también a Membership. Dentro del decorador, vemos que inyectamos la implementación BasicMempership (@Basic) y la anotamos con @Delegate para indicar que ese bean será decorado. A continuación, sobreescribimos el método de la interface y añadimos la lógica de negocio que deseamos. En nuestro caso, agregar 25 CDs gratis. Por último hacemos uso del decorador: Código
Vemos que NO inyectamos al decorador, si no al bean normal (@Basic). El contenedor se encarga de añadir la lógica del decorador al método del bean. Si ejecutamos, vemos ésta salida: Código: Información: [+] Clase decoradora para Membership El orden es porque yo he ejecutado primero la lógica del decorador y al último del bean. Si hubiera sido al revés, el resultado hubiera sido invertido. Los decoradores no están activados por defecto en CDI, así que debemos listarlos en el descriptor beans.xml: Código
Eventos Los eventos permiten a los beans interactuar con sus dependencias en tiempo de no-compilación. Cuando un bean define un evento, otro bean puede disparar el evento e incluso otro bean puede manejar el evento. Los beans pueden estar en paquetes y capas distintos dentro de la aplicación. El esquema que siguen éstos eventos es el observer/observable, de Gand of four. Los productores de los eventos disparan los eventos usando la interface Event (javax.enterprise.event.Event). Un productor eleva eventos llamando el método fire(), pasando el objeto asociado al evento. Veamos un ejemplo. En nuestra tienda online de CDs, cada vez que se quiera agregar un ítem al carro, deseamos disparar un evento CDI que envíe el ítem que se desee agregar al método observador addItem y reciba el ítem elegido por el usuario para que se agrege al carro. Vamos con nuestro bean CDShopCart: Código
Este bean tendrá un alcande de petición (@RequestScoped), es decir que su ciclo de vida será igual al de una petición HTTP. Esto es así porque solo vamos a utilizar este bean para agregar un ítem (CD) al carro. Vemos que hemos definido una propiedad tipo Event que acepta datos tipo CD. Cuando se ejecute el método addItem2cart, se ejecutará el evento CDI y se enviará un bean CD para que sea procesado por el método observador, que lo define la siguiente clase: Código
El método addItem() es el método observador. Este método escucha el evento y cuando se lanza lo captura y recibe el objeto asociado con el evento lanzado, en este caso CD. Es conveniente que la entidad CD sea pasivada (implemente Serializable). Además, vemos que el carro de compras está marcado como @SessionScoped ya que el carro de compras estará ligado siempre a la sesión de un usuario. Para disparar el evento, podemos usar JSF, por ejemplo: Código
Cuando se haga click en el botón, se ejecutará el método y se lanzará el evento. Si hacemos click, veremos lo siguiente en el log: Código: Información: Nuevo CD añadido al carro Ahora, para hacer más interesante nuestro ejemplo, podemos crear calificadores llamados @Added y @Removed para identificar a cada evento: Agregar y Eliminar. Para esto, debemos hacer unos pequeños cambios: Debemos cambiar el alcance de CDShopCart de @RequestScoped a @SessionScoped: Código
Los métodos observadores del carro, se verán así: Código
Prestar atención al calificador después de @Observes. Esto identifica al evento disparado, @Added representa un nuevo CD agreado y @Removed eliminará un CD del carro. Nuestra web, se verá así: Código
(http://i.imgur.com/GXt4ni1.png) Descarga en PDF https://mega.nz/#!bpBmxSAA!ize0-Dy5Urqh20AP-jH_18mwIEcsjAjQnNNGvRkwiFQ Eso es todo lo que quería compatirles acerca de CDI. Es un tema muy importante y que pocos entienden y comprenden cómo funciona. Espero que el presente documento es ayuda a entender un poquito mejor cómo funciona CDI y sus nuevas características. Nos vemos en otra oportunidad, hasta la próxima. |