La inyección de dependencias con Jakarta CDI ya no guarda secretos. Tenemos los conocimientos suficientes para afrontar casi cualquier necesidad que surja al trabajar con inyecciones y CDI beans en nuestros proyectos Jakarta EE. No obstante, vamos a estudiar funcionalidades adicionales derivadas de la naturaleza del contenedor de CDI y sus “proxy”. Su uso no es muy habitual, pero no están de más en nuestra “caja de herramientas”.

Seguir leyendo

En ocasiones necesitamos intervenir en la creación de los objetos de CDI ejecutando nuestro propio código. O, tal vez, la estrategia consistente en definir CDI beans anotando las clases con calificadores y ámbitos es insuficiente. Ningún problema, los productores acuden al rescate.

Seguir leyendo

Tras abordar la inyección de dependencias que ofrece CDI y sus ámbitos, continuamos profundizando en el uso de esta técnica. Estudiaremos funcionalidades más avanzadas que permitirán abarcar un amplio abanico de situaciones que encontraremos en nuestro día a día desarrollando aplicaciones con Jakarta EE.

Seguir leyendo

Hemos comprobado que la bitácora (logs) de WildFly se muestra en la salida estándar y en un fichero. El uso del sistema de logging del servidor y, por extensión, en nuestro código, es fundamental en la detección y corrección de problemas. Se utiliza para registrar mensajes que contienen trazas de errores e información de cierta relevancia gracias a los que podemos conocer qué está haciendo nuestra aplicación en cada momento. Sin estos mensajes, iremos a ciegas cuando tengamos que comprobar su funcionamiento.

Seguir leyendo

La primera especificación de Jakarta EE\ Java EE que vamos a estudiar en profundidad es una de las más importantes aunque suele pasar desapercibida en comparación con Jakarta Persistence o Jakarta REST. Pero Jakarta CDI, abreviatura de “Contexts and dependency injections” (inyección de contextos y dependencias), es el pilar sobre el que construiremos nuestras aplicaciones.

Seguir leyendo

En el capítulo anterior conseguimos ejecutar las pruebas automáticas en un contenedor de una imagen de WildFly creada a medida de nuestras necesidades, aunque puede parecer que no hemos avanzado mucho: seguimos teniendo que arrancar el servidor manualmente. Vamos a remediar esto.

Seguir leyendo

En los dos capítulos anteriores hemos realizado un breve repaso al funcionamiento de Docker. En el contenido restante de este bloque aplicaremos lo aprendido en nuestro día a día como desarrolladores de aplicaciones Jakarta EE. Empecemos aprendiendo cómo desplegar proyectos en un WildFly “dockerizado” desde IntelliJ y Eclipse.

Seguir leyendo

Tras la introducción teórica, espero que el lector haya comprendido el enorme potencial que ha convertido a Docker en todo un estándar. Si no es así, lo descubrirá por sí mismo a medida que aprenda a sacarle partido en su día a día. Antes de introducirlo en nuestros proyectos, veamos cómo utilizarlo de forma muy básica. Y es que, a pesar de que este capítulo es algo más largo de lo habitual, Docker requiere de un curso específico y extenso para conocerlo en profundidad que queda muy lejos del propósito de este curso dedicado al desarrollo con Jakarta EE.

Seguir leyendo

Con Arquillian podemos probar a fondo nuestras aplicaciones de forma realista desplegando lo que necesitemos en el servidor para realizar test de integración, end-to-end, aceptación, etc. Las pruebas van a complicarse a medida que avancemos en el curso porque necesitaremos un entorno más complejo en el que, además de WildFly, tendremos un servidor de bases de datos MySQL. Y resulta de vital importancia que sea lo más parecido posible al entorno de explotación final de la aplicación.

Seguir leyendo

Para realizar pruebas unitarias, tenemos suficiente con JUnit 5 y AssertJ. Pero cuando llegue el momento de los test de integración y end-to-end, necesitaremos usar los servicios de WildFly, o bien disponer de la aplicación desplegada en el servidor para la ejecución de pruebas que simulen clientes remotos.

Seguir leyendo