-Enviar jms desde Wildfly a JBoss5:
Para poder hacer esto hay que usar un «jms-bridge». Esto lo que hace es usar una cola de Wildfly para enviar los mensjaes y luego reenviarlos a la cola de destino. Esto se puede hacer para JBoss, ActiveMq, … cualquier cola que queramos.
Primero hay que crear un módulo con los jars necesarios para poder conectarse a esa cola, nosotros lo llamaremos «org.jboss.as.jms-client» y lo meteremos en la caprtea del modulo que corresponda «modules/system/layers/base/org/jboss/as/jms-client/main:
<?xml version=»1.0″ encoding=»UTF-8″?>
<module xmlns=»urn:jboss:module:1.3″ name=»org.jboss.as.jms-client»>
<resources>
<resource-root path=»jboss-mdr.jar»/>
<resource-root path=»javassist.jar»/>
<resource-root path=»trove.jar»/>
<resource-root path=»jboss-common-core.jar»/>
<resource-root path=»jboss-aop-client.jar»/>
<resource-root path=»jboss-metadata.jar»/>
<resource-root path=»jboss-remoting.jar»/>
<resource-root path=»jboss-logging-spi.jar»/>
<resource-root path=»jnp-client.jar»/>
<resource-root path=»jboss-messaging-client.jar»/>
<resource-root path=»jbossall-client.jar»/>
<resource-root path=»concurrent.jar»/>
<resource-root path=»jboss-logging-log4j.jar»/>
<resource-root path=»log4j.jar»/>
</resources>
<dependencies>
<!– add the dependencies required by JMS Bridge code –>
<module name=»javax.api» />
<module name=»javax.jms.api» />
<module name=»javax.transaction.api»/>
<module name=»org.jboss.remote-naming»/>
<!– we depend on org.hornetq module since we will send messages to –>
<!– the HornetQ server embedded in the local WildFly instance –>
<module name=»org.hornetq» />
</dependencies>
</module>
Los jars que hay que meter se sacan de una distribución de JBoss5 de la carpeta «client» y «common/lib/».
La configuración del jms-bridge es la siguiente:
…
<jms-queue name=»cometEvent»>
<entry name=»java:/jms/queue/cometEvent»/>
<durable>true</durable>
</jms-queue>
</jms-destinations>
</hornetq-server>
<jms-bridge name=»event-bridge» module=»org.jboss.as.jms-client»>
<source>
<connection-factory name=»ConnectionFactory»/>
<destination name=»java:/jms/queue/cometEvent»/>
</source>
<target>
<connection-factory name=»/ConnectionFactory»/>
<destination name=»java:/queue/CometEventGwQueue»/>
<context>
<property key=»java.naming.factory.initial» value=»org.jnp.interfaces.NamingContextFactory»/>
<property key=»java.naming.provider.url» value=»jnp://jboss5.local:1099″/>
<property key=»java.naming.factory.url.pkgs» value=»org.jboss.naming:org.jnp.interfaces»/>
</context>
</target>
<quality-of-service>AT_MOST_ONCE</quality-of-service>
<failure-retry-interval>10000</failure-retry-interval>
<max-retries>1</max-retries>
<max-batch-size>10</max-batch-size>
<max-batch-time>100</max-batch-time>
<add-messageID-in-header>true</add-messageID-in-header>
</jms-bridge>
</subsystem>
…
Se escribe en la cola local «java:/jms/queue/cometEvent» y esto redirecciona al JBoss5 que se encuentra en el servidor «jboss5.local» a la cola «java:/queue/CometEventGwQueue».
Con esto se desacopla la logica de nuestro aplicativo de usar librerias externas.
Nota: Si se deja el «max-retries» con 1 esto hara que solo intente reconectar el bridge 1 vez a los 10 segundos (failure-retry-interval). Tenemos que ponerlo a «-1» para que intente reconectar todo el rato.
0 comentarios