In our system we have proved out looking up the JMS connection factory from JNDI, but up to this point we have declared the Queue bean using an <amq:queue> element in the application bean files. This ties our application code to the ActiveMQ broker, which we don’t want. We want to move toward looking up the connection factory and the queue from JNDI. That way the application bean file only needs to know the JNDI name, and we can configure the queue in the connection factory datasource configuration file on the app server (e.g., activemq-jms-ds.xml), probably as an mbean element in there:
<mbean code="org.jboss.resource.deployment.AdminObject" name="activemq.queue:name=TheMBeanNameYouSeeInTheJMXConsole"> <attribute name="JNDIName">this/is/the/jndi/name/the/bean/files/will/use</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='activemq-rar-5.1.0.rar'</depends> <attribute name="Type">javax.jms.Queue</attribute> <attribute name="Properties">PhysicalName=theQueueName.YouWillSee.In.ActiveMQ</attribute> </mbean>
But Who Will Care for the Babies?
This will be fine for a production environment — but what about our integration tests? Right now we use Bitronix Transaction Manager 1.3’s JNDI server facilities to provide JNDI lookup of the JDBC datasource for our integration tests. I thought we’d also use BTM to look up the JMS connection factory… but BTM does not support JNDI-looking-up queues as well. Ludovic says:
If you really need a complete JNDI server, you can use Tomcat’s which is quite easy to reuse. This is what I recommended using before BTM 1.3, there is an example here: http://docs.codehaus.org/display/BTM/Hibernate
That’s probably what we’ll need to look into when the time comes…