Entradas

Mostrando las entradas con la etiqueta java ee

Jakarta EE 8 | JSF: Validación básica con JSF

Imagen
Seguimos con los vídeos de JSF. Ahora veremos cómo validar unos campos en JSF: que no sea blanco que sea un campo email. Sin utilizar algún widget de Javascript, y sin agregar mucho más código. Finalmente, seguiremos teniendo un .war totalmente liviano. Si gustó el vídeo dale like ; si te es útil, compártelo .. es gratis.

Instalando Apache NetBeans 9 con componentes Java EE | Jakarta EE

Imagen
En este vídeo veremos cómo instalar Apache NetBeans 9, y configurarlo para que funcione con los módulos de Java EE | Jakarta EE. A la fecha de este vídeo el IDE solo permite desarrollar con Java SE, ya que Oracle está liberando (después de una exhaustiva revisión) el código para donarlo a la Fundación Apache. Pero como NetBeans es modular, se pueden agregar los módulos que se utilizan en la versión anterior. En el vídeo lo explico. Los enlaces utilizados son los siguientes: Los plugins de 8.2:  https://blogs.apache.org/netbeans/entry/what-s-happened-to-my Plugins de Payara para NetBeans: https://github.com/payara/ecosystem-netbeans-plugin/releases Happy NetBeaning! Social Twitter Video: Instalacion de @netbeans 9 con Soporte para #JakartaEE y @Payara_Fish https://t.co/zm9ThFwzbQ — ☕ Apuntes de Java ☕ (@apuntesdejava) 14 de agosto de 2018 Facebook

Pruebas Unitarias a JPA y servicios REST con Arquillian + Payara. (4/4) - Empaquetando el Servicio

Imagen
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.

Pruebas Unitarias a JPA y servicios REST con Arquillian + Payara. (3/4) - Probando el Servicio

Imagen
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.

Pruebas Unitarias a JPA y servicios REST con Arquillian + Payara. (2/4)

Imagen
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.

Java EE 8: Bean Validation

Imagen
En Java EE 8, el api Bean Validation ha venido con mejoras. Por ejemplo, ahora podemos validar un campo de tipo java.time.LocalDate @Past private LocalDate fechaIngreso; También, determinar los límites de una lista: @NotEmpty private List<@Size(min = 1, max = 15) String> proyectos; Al igual que un nuevo tipo de validación (y así evitar log RegEx) @Email private String email; Podemos evaluar los campos validados desde el mismo Java (aquí un ejemplo desde una prueba unitaria): @Test public void testMemberWithNoValues() { Empleado e = new Empleado(); e.setEmail("abc@"); e.setDni("12345678"); e.setProyectos(Arrays.asList("Proyecto 1", "Proy2", "Proy3")); // validate the input ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Set<ConstraintViolation

Java EE 8 - Json Binding

Imagen
Una de las nuevas características de Java EE 8 es el api de JSON-B, o Json Binding, que consiste en mapear cada entrada de un dato json a un objeto java.

Opinión: La alternativa de Java EE

Imagen
Si vamos a usar un servidor Java EE (perfil completo) para implementar una solución, recomiendo utilizar todas las funcionalidades que vienen en la especificación: EJB, JPA, JMS, etc. Pero hay veces que no podemos contar con un servidor de ese tipo ya que, por ejemplo, el cliente no conoce más allá del Tomcat, o no exista gente que podría administrar un servidor como GlassFish, Payara, Weblogic, etc. Entonces, llegamos a extrañar las funcionalidades dadas por Java EE, y optamos por otros frameworks que sí nos ayudan en nuestros momentos de limitaciones de servidor. Spring ayudó mucho desde un inicio cuando no se contaba con servidores Java EE OpenSource completos. Caló tan fuerte entre los desarrolladores, que practicamente se ha hecho un "estándar" alterno a Java EE. Cuando los arquitectos de Java EE "despertó" y mejoró las especificaciones en la versión 5, pienso yo, ya era muy tarde. Tomcat siguió siendo el servidor "estándar" para aplicaciones