Eclipse MicroProfile 3.1: Primicias

Tabla de Contenidos

  1. Health 2.1
  2. Metrics 2.1
  3. Conclusión

En este artículo les escribiré respecto a la onceava iteración de Eclipse MicroProfile; la versión 3.1 que fue liberada el pasado 13 de Octubre.

Esta versión trae dos cambios menores con respecto a la versión 3.0, el primero de ellos es la actualización a Metrics 2.0 y el otro el paso a Health 2.1. Estos cambios no generan problemas de compatibilidad, como sucedió cuando pasamos a MicroProfile 3.0.

Seguidamente veremos los cambios más relevantes:

Health 2.1

En el caso de este API, la documentación oficial nos indica que se agregó un nuevo método para crear respuesta y una nueva propiedad de configuración para deshabilitar los procedimientos de implementación de los Health Checks; además de mejoras en cuanto al JavaDoc, tests y otros detalles que pueden encontrar aquí.

En el caso del nuevo método, es más que todo una conveniencia para el desarrollador; anteriormente teniamos que hacer algo como:

@Readiness
@ApplicationScoped
public class DemoReadinessCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        return HealthCheckResponse.named("Readiness")
            .up().build();
    }
}

Ahora podemos resumirlo en:

@Readiness
@ApplicationScoped
public class DemoReadinessCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        return HealthCheckResponse.up("Readiness");

        // O si debemos retornar un down
        // return HealthCheckResponse.down("Readiness");
    }
}

El segundo cambio tiene que ver con que una implementación de este API puede proveer un procedimiento por omisión para los Health Checks; pero ahora podemos usar la propiedad mp.health.disable-default-procedures=true. Esto hace que nuestra aplicación procese y despliegue sólo los procedimientos de verificación que nosotros establezcamos.

Metrics 2.1

Esta actualización incluye varias aclaraciones como por ejemplo: que no se deben crear métricas sobre métodos privados cuando la clase esta anotada, que las implementaciones del metric registry sean thread safe entre las más relevantes.

Además, en 2.0 la métrica Guage se suponía que únicamente podía manejar valores numéricos, pero algunos usuarios empleaban valores no numéricos como String. La versión 2.1 ahora limita de manera explícita a que sólo se empleen valores numéricos a partir de java.lang.Number.

Un mayor detalle de todas ellas los puedes encontrar aquí.

El caso que me parecio más interesante es cuando algunas implementaciones retornaban métricas sobre métodos privados, por ejemplo:

# TYPE application_dev_gerardo_demo_Prueba_metodoPublico_total counter
application_dev_gerardo_demo_Prueba_metodoPublico_total 4
# TYPE application_dev_gerardo_demo_Prueba_metodoPrivado_total counter
application_dev_gerardo_demo_Prueba_metodoPrivado_total 0

y que ahora muestran correctamente únicamente los públicos

# TYPE application_dev_gerardo_demo_Prueba_metodoPublico_total counter
application_dev_gerardo_demo_Prueba_metodoPublico_total 4

Como vemos, no trae un cambio considerable en la forma en que usamos Metrics; pero si allana el camino para las próximas versiones de este útil API.

Conclusión


En este artículo exponemos los principales cambios menores que trae MicroProfile 3.1 y que especialmente HealthCheck nos ahorra algunas líneas código.

Written by

Gerardo Arroyo Arce

Arquitecto de Soluciones AWS certificado x10 con pasión por compartir conocimiento. Como miembro activo de AWS Community Builders, ex-AWS Ambassador y AWS User Group Leader, me dedico a construir puentes entre la tecnología y las personas. Desarrollador Java de corazón y consultor independiente, llevo la arquitectura cloud más allá de la teoría a través de conferencias internacionales y soluciones del mundo real. Mi curiosidad insaciable por aprender y compartir me mantiene en constante evolución junto a la comunidad tech.

Inicia la conversación