Autor: Cesar Hernandez M.

Docker y debug de Apache Tomcat y TomEE

El debug remoto es una práctica común para investigación de problemas de microservicios.Si estas utilizando contenedores Docker Apache Tomcat o Apache TomEE, en la web puedes encontrar varias técnicas como lo son:Extender una imagen oficial y personali…

Etiquetado con: , , , ,

Vota para el nuevo nombre que reemplazará a Java EE

Como ya saben, Oracle sigue en el proceso de donar JavaEE a la fundación Eclipse bajo el proyecto sombrilla llamado: Eclipse Enterprise for Java (ee4j).  La primera fase para selectionar la el nombre de la marca ya concluyo y ahora se ha iniciado un segunda fase que incluye la votación entre los dos nobres finalistas de la primera fase.

Esta marca también será utilizada en la certificación en la industria para implementaciones compatibles e independientes. Los proyectos de código abierto que se incluyen en el proyecto de nivel superior Eclipse EE4J serán una de esas implementaciones. En resumen, necesitamos un nuevo nombre para reemplazar “Java EE”. Al igual que el proyecto OpenJDK implementa la especificación de la plataforma Java SE, los proyectos EE4J proporcionarán implementaciones de un conjunto de especificaciones que hoy llamamos Java EE.

Deja tu voto en la historia tecnológica, vota hoy dado que el último día para votar es el 23 de Febrero de 2018:

Etiquetado con: , , , ,

Vota para el nuevo nombre que reemplazará a Java EE

Como ya saben, Oracle sigue en el proceso de donar JavaEE a la fundación Eclipse bajo el proyecto sombrilla llamado: Eclipse Enterprise for Java (ee4j).  La primera fase para selectionar la el nombre de la marca ya concluyo y ahora se ha iniciado un segunda fase que incluye la votación entre los dos nobres finalistas de la primera fase.

Esta marca también será utilizada en la certificación en la industria para implementaciones compatibles e independientes. Los proyectos de código abierto que se incluyen en el proyecto de nivel superior Eclipse EE4J serán una de esas implementaciones. En resumen, necesitamos un nuevo nombre para reemplazar “Java EE”. Al igual que el proyecto OpenJDK implementa la especificación de la plataforma Java SE, los proyectos EE4J proporcionarán implementaciones de un conjunto de especificaciones que hoy llamamos Java EE.

Deja tu voto en la historia tecnológica, vota hoy dado que el último día para votar es el 23 de Febrero de 2018:

Etiquetado con: , , , ,

Deconstruyendo y evolucionando la seguridad en servicios REST | Desconferencia GuateJUG

El pasado jueves 1 de Febrero tuve la oportunidad de poder compartir con la comunidad de usuario java en Guatemala –GuateJUG– en el inicio de actividades que este año el JUG realizará. La representación tanto local como de empresas del área Centroamericana estuvieron representadas y pudieron compartir un buen café y muchas opiniones sobre un tema en particular.  Durante la actividad presenté el tema: Deconstruyendo y evolucionando la seguridad en servicios REST.

Me agradó mucho la diversidad tecnológica en los participantes y compartir con amistades de diferentes etapas académicas y profesionales de mi vida y que siguen tiendo en común la pasión por la tecnología, música, el open source y sinergia producto de colaboración en comunidad.

Etiquetado con: , , ,

Organizando Class Loaders en Apache Tomcat

El dilema

Cuando se están diseñando aplicaciones Java que serán desplegadas en un Servlet Container, Web Profile o full JavaEE Application server, se puede llegar a la necesidad de utilizar dependencias (.jars) que no son parte de la especificación estandard y por consiguiente entrar en el dilema: 
  1. Que el empaquetado (.war) incluya dicha(s) dependencia(s). Comúnmente utilizando un sistema gestor de dependencias como por ejemplo maven y su scope: compile.
  2. Que la(s) dependencia(s) se encuentre(n) en el container donde la aplicación será desplegada. En maven utilizando el scope: provided para evitar que el gestor de dependencia incluya los jars dentro del empaquetado.

Seleccionando una solución

Seleccionando para el resto de este artículo la opción número 2 y tomando como ejemplo el Servlet Container más famoso de mundo, Apache Tomcat, a continuación listo algunas de las ventajas y desventajas de dicho enfoque:

Ventajas:
  • Optimización de espacio de disco duro en el sistema host de la instalación de Tomcat
  • Estandarización en los ambientes de deployment
  • Empaquetados (.war) con menor tamaño que contribuyen a reducir tiempos en pipelines de Integración y Entrega continua.
  • Útil cuando lo que se promueve entre ambientes es el artefacto (.war) y no el código fuente.
Desventajas:
  • La instalación de tomcat empieza a convertirse en una personalizada y no estándar.
  • Requiere que tanto los ambientes locales de desarrollo como los diferentes ambientes de producción estén sincronizados con la última versión personalizada de Tomcat.
  • Cambios en una dependencia es replicable para todas las aplicaciones desplegadas en la instancia de Tomcat y si estas poseen diferentes arquitecturas se tendrá que tomar una decisión de no realizar el cambio o desplegar las aplicaciones incompatibles en otra instancia de tomcat. el resultado final será una nueva instancia personalizada.

Class Loaders 101 en apache Tomcat

Acorde a la documentación oficial tomcat provee 3 jerarquías de Class Loaders:
  • Bootstrap: Carga las clases básicas de ejecución provistas en los jars de la JRE que utiliza la instancia de Tomcat.
  • System: Se inicializa a partir del contenido de la variable de ambiente classpath.
  • Common: Carga clases adicionales que normalmente se encuentran en jars ubicados en: $CATALINA_HOME/lib
  • Webapp: Para cada aplicación desplegada tomcat crea un class loader que carga clases ubicadas en /WEB-INF/classes  y clases dentro de jars ubicados en /WEB-INF/lib
La figura 1 describe la jerarquía:
      Bootstrap
|
System
|
Common
/
Webapp1 Webapp2 ...
Figura 1.
La Figura 2 describe el orden por default de class loaders que una aplicación desplegada enTomcat 9 utiliza en orden ascendente:
                 Bootstrap (1)
|
System (4)
|
Common (5)
|
WebappX
/
/WEB-INF/classes (2) /WEB-INF/lib/*.jar (3)
Figura 2.

Iniciando a implementar la solución

Un primer enfoque que en muchos tutoriales realizan con los JDBC Drivers es posicionar los jars en la carpeta: $CATALINA_HOME/lib. Esto hará que el class loader Common incluya dichas dependencias en el orden y jerarquías especificados en las figura 2.

Optimizando la solución

Por simple lógica se pude observar en la Figura 1. que tanto System como Common  ponen a disposición de las aplicaciones las clases que cada uno carga, sin embargo la recomendación es que no utilicemos Common (por ende la ubicación $CATALINA_HOME/lib) para exponer clases de jars que queremos compartir entre las aplicaciones desplegadas en la instancia de Tomcat.
Un enfoque recomendado es posicionar las clases y/o dependencias necesarias en los directorios:
$CATALINA_HOME/shared/lib y
$CATALINA_HOME/shared/classes

Quedando como último paso indicarle a tomcat que tome en consideración las rutas anteriormente descritas para que este nuevo class loader (shared) sea tomando en consideración luego de common. Para realizar esto debemos de editar el archivo: 
$CATALINA_HOME/conf/catalina.properties
y dentro del archivo especificar las rutas en:
shared.loader=”${catalina.base}/shared/classes”,”${catalina.base}/shared/lib/*.jar”

Etiquetado con: , , , , , , ,
Top