En JBoss EAP 6, se puede hacer una configuración de modulos en el core de JBoss que contengan librerías que pueden ser utilizadas por todos los proyectos.
En ocasiones, cuando se tienen varias aplicaciones en un mismo servidor JBoss, puede ser que varias aplicaciones utilicen las mismas librerías y que puedan ocasionarse conflictos por librerías duplicadas.
JBoss resuelve los conflictos asignando prioridades en el classloader para la carga de las clases, que se indica a continuación:
• La prioridad máxima es para los módulos.
• Después, las librerias indicadas como dependencias en el MANIFEST.MF del archivo empaquetado, o en el archivo jboss-deployment-structure.xml.
• A continuación, las librerías empaquetadas en la propia aplicación, tales como las clases contenidas en WEB-INF/lib o WEB-INF/classes.
• Por último, las librerías empaquetadas en el mismo archivo EAR (en el directorio lib del EAR).
Generar módulos en el core de JBoss tiene sus ventajas:
• Será lo primero que cargará el classloader.
• Como se encuentran en el core de JBoss, es visible para cuando el servidor se arranca en modo domain o standalone, útil para cuando se utiliza el servidor en cluster.
• Los módulos son utilizados bajo demanda, haciendo mas eficiente el uso de recursos.
Instalar el módulo:
Supongamos que queremos añadir el jar de spring para todas nuestras aplicaciones que residirán en nuestro servidor.
• Nos ubicamos en la ruta $JBOSS_HOME\\modules\system\layers\base\org\
• Creamos el directorio org\springframework\main
• En este directorio, copiamos el jar spring2.5.6.jar
• Creamos el archivo module.xml, indicando el nombre del módulo, el jar y en caso de ser necesario, las dependencias. El archivo tendrá el siguiente código:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.springframework">
<properties>
<property name="jboss.api" value="unsupported"/>
</properties>
<resources>
<resource-root path="spring-2.5.6.jar"/>
<!-- Insert resources here -->
</resources>
</module>
Con esto quedaría generado el módulo listo para ser utilizado.
IT-blog
Con los avances tecnológicos, no podemos quedarnos atrás. Este blog nace por la necesidad de renovarse después de trabajar en un sitio que no utiliza lo último en tecnología.
martes, 7 de octubre de 2014
ClassLoader de JBoss EAP 6
Etiquetas:
administracion JBoss,
ClassLoader,
EAP,
JBoss,
JBoss 6,
RedHat
martes, 20 de mayo de 2014
Creación de clusters en JBoss EAP, modo standalone
La generación de clusters en EAP es para tener alta disponibilidad del servicio. En JBoss EAP 6, no es necesario generar dos configuraciones de servidor JBoss para hacer clusters, pero si crear un nuevo archivo XML.
La generación de clusters en EAP es para tener alta disponibilidad del servicio. En JBoss EAP 6, no es necesario generar dos configuraciones de servidor JBoss para hacer clusters, pero si crear un nuevo archivo XML.
La configuración standalone en cluster es útil para entornos de desarrollo, debido a que solo puede contener un perfil de configuración. Por lo general, se utiliza el archivo standalone-ha.xml. Es buena páctica hacer un respaldo del archivo original antes de hacer modificaciones.
Con la configuración standalone, se pueden hacer cluster con los equipos ejecutandose en el mismo servidor o residiendo en distintos servidores.
Los clusters se suelen utilizar con balanceadores de carga, y en JBoss EAP 6, el balanceador se hace con apache server, pero eso se verá en otra entrada.
Al primer archivo, lo llamaremos standalone-ha-node1.xml
En este archivo, revisaremos la etiqueta <interfaces>, que debe apuntar hacia la ip de nuestro servidor, en este caso, localhost (127.0.0.1)
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>
y en la parte de los sockets, lo dejamos sin cambios para el primer servidor:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
Para el segundo server, crearemos otro archivo standalone-ha-node2.xml. Solo que en este configuraremos un offset de puertos en el socket binding:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:100}">
Asi mismo, para evitar conflicto de puertos, en el archivo standalone-ha-node2.xml cambiaremos los puertos de administración:
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:100}">
<socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
Servidor 1
D:\programas\jboss-eap-6.2\bin>standalone.bat --server-config=standalone-ha-node1.xml
Servidor 2
D:\programas\jboss-eap-6.2\bin>standalone.bat --server-config=standalone-ha-node2.xml
Podremos ver el servidor 1 en el puerto 8080:
y el servidor 2 en el puerto 8180:
Y con esto podremos ver dos servidores en clúster, donde podremos desplegar las aplicaciones con un balanceador de carga, para lo cuál apache nos servirá, y una aplicación distribuida en clúster, pero eso será tema de otra entrada.
Etiquetas:
administracion JBoss,
cluster,
cluster standalone,
EAP,
JBoss,
RedHat,
standalone
Suscribirse a:
Entradas (Atom)