Translate

sábado, 30 de enero de 2016

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"

martes, 8 de diciembre de 2015

I'm part of the OTN Speaker Bureau


OTN Speaker Bureau

I'm glad to inform you that I was accepted to be part of the Oracle Technology Network Speaker Bureau :). 

The Speaker Bureau is a new place where you can find, connect and request topnotch speakers from the IT Industry around the world including Oracle employees and community members such as Oracle ACEs, Java Champions, and other community evangelists. 

This resource is a excellent way in which conference planners, event organizers, journalists,  Java and Oracle communities and the general public can find and request expert speakers according with area of expertise, geographic location, languages spoken, certifications, and other criteria.

My Bureau profile page:
https://community.oracle.com/people/cesarHernandezGT?customTheme=osb

OTN Speaker Bureau home page
https://community.oracle.com/community/otn-speaker-bureau




[Español]
Me alegra informarles que fui aceptado para formar parte de laOracle Technology Network Speaker Bureau :).

Speaker Bureau es un nuevo lugar donde se puede encontrar, conectar y solicitar conferencistas de primera categoría en la industria de TI al rededor del mundo. Incluye a los empleados de Oracle y miembros de la comunidad, tales como Oracle ACE, Java Champions, y otros evangelistas de la comunidad Oracle y Java.

Este recurso es una excelente manera en la que los planificadores de conferencias, organizadores de eventos, periodistas, comunidades de Java y Oracle así como el público en general pueden encontrar y solicitar conferencistas expertos de acuerdo con el área de especialización, ubicación geográfica, idioma, certificaciones y otros criterios.

lunes, 16 de noviembre de 2015

JavaOne 2015 Recap


This year JavaOne came, as usually, with a lot of surprises, experiences and lessons learned. One thing that is for sure is the fact that JavaOne has a huge community soul that is and will last as long as we  (the communities) continue contributing to it.

One of the best moments regarding  Java 20th anniversary celebration was the  clever  Java Community Keynote leaded by Stephen Chin. It's incredible how a technology has evolve over 20 years and be today  stronger than ever before.  I'm glad to be part of a tiny portion of those 20 years and also thankful for all the good friends that I have in my country and all over the world because of this passion for technology.

The Java Hub was a great place with a lot of interesting wearables/IoT projects, robotics, 3D Printing and with collaboration spaces like hackergarten, Night Hacking interviews and much more. I was able to catch up updates about OpenJdk, some JSR's and others Open Source Projects.  I also had the chance to promote the JEspañol community that aims to generate synergy among the Latin American Java User Groups whose main language is Spanish.

Besides my Rock Code And Roll participation, this year I focused on attending conferences and hands on labs related with Containers orchestration, micro/pico/nano services (you name it) and Java EE. I'll do my best to reserve some time to post some tips and tricks related with this topics over the following months.

Here you can find a index of resources to catch up about the conferences, keynotes, interviews and complementary materials:

Finally, I want to thanks to Deiby Gomez, Nichole Scott, Heather VanCura, The Null Pointers (Freddy Guime, Frank Greco, Ed Burns, Mattias Karlsson, Zoran Sevarac, Peter Pilgrim, Hiroshi), Andres Almiray,  Ixchel Ruiz, Alexis López and Bruno Borges for their support that was crucial for me to be able to attend and be actively involved in the conference.



 Photo Gallery
Photo Gallery