Uno de los servidores JEE que mas se usa a día de hoy es JBoss ya sea a traves de su sistema de licencias o como versión de comunidad. En su versión 6.0 EAP o 7.0 de comunidad ha incorporado un nuevo concepto denominado JBoss Modules que vuelve loco a la mayoría de la gente . Vamos a hablar de ello un poco a detalle en este articulo .
WAR y administradores de sistemas
Una de las cosas que mas se quejan los administradores de sistemas es del problema de las librerias java (ficheros JAR) y su uso en las distintas aplicaciones . Ya que en muchas casos nos encontramos con librerias repetidas en cada aplicación lo cual para ellos no cumple con el principio DRY de no repetir pero en este caso no código sino ficheros JAR.
Librerías Compartidas
Para evitar este tipo de problemas los administradores optan habitualmente por usar algún tipo de carpeta compartida (shared library) que el servidor soporte . De esta manera pueden tener las librerías ubicadas en un único lugar y obligar a que todas las aplicaciones primero revisen esta carpeta a la hora de cargar las distintas clases.
Librerias y versionado
Lamentablemente esto que parece una buena solución como punto de partida acaba no siéndolo en la practica debido a dos problemas esenciales . El primero es el problema de versionado ya que muchas veces tenemos la necesidad de tener varias versiones de librerias en un mismo servidor de aplicaciones ya que cada aplicación usa unas distintas . Por ejemplo una aplicación usa Hibernate 3.6 y otra mas moderna Hibernate 4.2.
Librerias y Singletons
Otro de los problemas mas habituales es el uso de objetos singletons por parte de los frameworks . Cuando estas clases se instancian unicamente crean un objeto que es único para toda la aplicación . Son habituales los casos de objetos que sirven para configurar cosas. El problema que añaden los singleton es que si los ponemos en una carpeta compartida en el servidor . Serán únicos para todas las aplicaciones lo cual causará problemas.
JBoss Modules
En JBoss han optado por una solución que parece de entrada interesante .Han definido un nuevo concepto el concepto de Módulo . Un Modulo puede incluir uno o varios jars
Ademas un módulo puede depender de otros módulos y agrupar así un conjunto de JARs
Jboss-deployment-structure.xml
Una vez entendido el concepto de módulo una aplicación puede a traves del fichero de configuración jboss-deployment-structure.xml añadir los módulos que desee y por lo tanto los JARs . De esta forma un administrador puede tener instaladas diferentes versiones de librerías (cada versión en un módulo) . Evitando tener ficheros repetidos de librerías cargados varias veces.
Modules y DRY
Con este diseño JBoss consigue facilitar a los administradores la gestión de las librerías utilizando el principio DRY (Dont Repeat YourSelft) a los ficheros JAR de cada una de las librerías que se encontrarán ubicados solo una vez en el servidor en el módulo que corresponda . Aunque esto parece óptimo tiene también sus problemas que abordaremos en artículos posteriores.
Hola… este es mi escenario:
1. Aplicación con ficheros JSP desplegada en WEBLOGIC.
2. Los JSP hacen referencia a ArrayList pero sin tener el import java.util.* —> WebLogic carga implicitamente esta libreria y no es necesario importarla
3. Se migra la aplicación a JBOSS, que no realiza la carga implicita…
4. Todos los JSP que no tienen el import java.util.* fallan en compilacion.
Pregunta: mediante la creación de un módulo llamemosle “libGenerico” se puede tener accesible la java.util sin necesidad de tener que poner el import java.util.* en los JSP??
Como serían este módulo (el archivo module.xml)?
Gracias.
El import lo tendrás que hacer de todas formas ya que el jsp lo necesita. Tendrás que adaptar tu module.xml para que incluya esta librería.
Luego de tu explicación me surge una consulta, ¿Como funciona el cargador de clases en jboss EAP? ya que según pude investigar al desplegar un EAR y este posee en su carpeta “lib” jars estos se cargan en un modulo “principal”, y los módulos que declaras en el archivo “jboss-deployment-structure.xml” se cargan en secciones separadas por decirlo de cierto modo, pero a mi parecer esto no resulta tan beneficioso, ya que en el ejemplo que mencionas el jarC no podría acceder a las clases que posee el jarA o el jarB, si es que no se ha referenciado. Al realizar… Read more »
Excelente articulo, segun lo indicado por tu persona un modulo es un conjunto de jars, es posible que un modulo sea un EAR que en su interior posean varios JARs??, gracias por absolver mi duda.
Saludos
No lo creo posible , los módulos no estan orientados a eso
Excelente articulo, todo esta muy claro, agradeceré despejarme esta pregunta: Es posible tener este escenario: – EAR01 (Componente web que posee los jsp y los controladores) – EARSHAREDLIB (Componente que posee la lógica del negocio) Ambos desplegados en el servidor de Jboss. ******Pregunta: Es posible referenciar al EARSHAREDLIB —- DESDE —– el EAR01 para que pueda consumir las clases. ********************************************************************************************************************************** La pregunta te la hago porque para componentes desplegados en servidores de weblogic, existe el descriptor weblogic-application.xml, en el cual se hace la referencia al sharedlib de tipo EAR que se desea consumir. De antemano muchas gracias por tu respuesta… Read more »
No es posible, lo que si es posibles es meter las librerias compartidas como “libreria” del primer EAR, en el directorio propio que tienen los EAR para jars compartidos
Cecilio, muchas gracias por la respuesta, de la cual me surge otra pregunta, entonces en JBOSS compartir librerias del negocio entre distintos EAR, se tendria que hacer de la siguiente manera:
– EAR01(lib->llibrerias negocio A)
– EAR02(lib->llibrerias negocio A)
Colocando en cada EAR las librerias del negocio a usar, no exite otra forma de referencias estas librerias en JOBSS???
Saludos, y muchas gracias por tu respuesta.
Muy buena explicación, los graficos dejan todo claro.
saludos.
Gracias 🙂