Apuntes de Java

Si tenemos una aplicación standalone (puede ser un JavaFX, de línea de comandos, batch, etc) que necesite consumir un endpoint hecho en RESTful, por lo general usaríamos algo como esto: public class RestClient { private static final String REST_URI = "http://localhost:8082/spring-jersey/resources/employees"; private Client client = ClientBuilder.newClient(); public Employee getJsonEmployee(int id) { return client .target(REST_URI) .path(String.valueOf(id)) .request(MediaType.APPLICATION_JSON) .get(Employee.class); } //... } (Tomado de https://www.baeldung.com/jersey-jax-rs-client ) Lo cual no está mal, pero creo que debería ser lo más transparente posible. ¿Cómo es eso? Si ven en la línea 13 del código anterior, significa que hay que decirle que haga un GET a la petición, además de pasarle el tipo de respuesta y otras cosas más. La cuestión se volvería algo compleja si queremos hace

Continuamos con nuestra serie de vídeos de Microprofile con Payara Micro. En este nuevo vídeo veremos cómo formatear las fechas en JSON desde la entidad JPA. Además, veremos cómo insertar registros en la tabla usando unas peticiones POST desde RESTful. El código fuente se encuentra disponible en este repositorio. https://bitbucket.org/apuntesdejava/microprofile-service-example/src/master/?at=post

En este vídeo veremos cómo acceder a una base de datos desde un endpoint REST, utilizando JPA, en Payara Micro.  La base de datos para el ejemplo se puede descargar desde aquí: https://github.com/datacharmer/test_db    El código fuente se este proyecto se puede descargar desde aquí: https://bitbucket.org/apuntesdejava/microprofile-service-example/src/jpa/

Ya hemos desarrollado el servicio, con acceso a base de datos, lógica de negocio, lo hemos probado tanto a nivel de EJB de base de datos, como probando el servicio REST. Ahora nos toca empaquetarlo todo en un solo .jar para poderlo ejecutar como servicio autónomo.

Ya tenemos la persistencia (JPA), ya tenemos la lógica de negocio (EJB) y con sus respectivas pruebas, ahora nos falta la parte principal del microservicio: el servicio. Así que haremos un par de servicios y sus respectivas pruebas con Arquillian.

Continuaremos con nuestro proyecto de prueba. Ahora lo configuraremos para que permita probar EJB que tendrán la lógica de negocio, y utilizando JPA como motor de persistencia.

Las pruebas unitarias son buenas y necesarias. Nos permiten evaluar ciertas porciones del proyecto antes de integrar y ejecutarlo todo. No vamos a esperar construir todo un auto para probar si funciona. Por tanto, solo probamos cada parte y nos aseguramos que cada prueba cumpla con ciertas características. Estas características son las que se definen en las Pruebas Unitarias. Si pasan estas características - o condiciones - recién se puede construir el proyecto. Aprovechando las fases de construir de Maven, podemos implementar pruebas unitarias para que - si aprueban las restricciones - pueda construir el proyecto sin problema. Pero ¿si necesitamos probar accesos a JPA o lógicas establecidas en RESTful? o más aún: ¿cómo podemos probar en un ambiente Java EE sin necesidad de desplegar un servidor Java EE? Aquí es donde entra   Arquillian . En esta serie de publicaciones  veremos desde preparar un ambiente Java EE para Arquillian, hasta hacer pruebas con JPA y RESTful. Al final l

Recuerdo un tiempo que  la gente (nivel usuario) pensaba que una computadora era siempre Windows + Office, hasta lo llamaban "Microsoft": - ¿Tu compu tiene Microsoft ? - ¿Office o Windows? - Microsoft XP . La gente pensaba así por default . Y algo así lo estoy viendo ahora con esta nueva tecnología llamada Microservicios : Solo se hace con SpringBoot. Pues bien, en este post mostraré  tres (03) frameworks en Java que permiten hacer Microservicios, sin usar SpringBoot.