HornetQ Server Deployment Timing Issue

[jfisherdev]

I am currently migrating some applications from JBoss AS 4.2.2 to WildFly 9.0.2. These applications will be deployed to a standalone WildFly server.

In the standalone.xml, I have configured a HornetQ server and defined the JMS destinations. I have also added org.hornetq as a global module [is this the right module if I want to do this or should it be org.jboss.as.messaging?], as a majority of the applications will need messaging capabilities.

This seems to be working for the most part; however, there is one case that seems to sometimes have issues.

Some of the applications I am deploying have start up MBean services that access JMS destinations. Sometimes this works, but other times it does not because of a NamingException, as the JNDI bindings for the managed JMS objects [connection factories and destinations] are not defined. Looking at the server log, it appears the deployment of managed JMS objects is happening after the deployment of an application that depends on the destination.

Is there a way to reliably ensure that the HornetQ server being started and managed JMS object deployment occur before application deployment?

Any information about this would be very much appreciated.

Message was edited by: Josh Fisher

[jbertram]

I don't know of any way in Wildfly to set an arbitrary dependency between a non-container-managed-resource (e.g. your MBean) and a POJO bound in JNDI.  You might be best served by simply having a wait/retry mechanism on your JNDI lookup.

[jfisherdev]

That may very well be a way to address this; however, having the HornetQ server reliably start and deploy the managed JMS objects before application deployment would be preferable. Looking at this discussion, I wonder if this is a case where resource injection might provide what I am looking for:

https://developer.jboss.org/message/925961#925961

[jbertram]

Injection does create an implicit dependency, but your MBean would need to be managed by the container somehow so support injection I believe.  I certainly could be wrong here, but I don't think you can just inject resources in just any bit of code you want.  Notice that the linked forum post was dealing with a "EJB marked as @Singleton @Startup".

[mnovak]

Could you try to modify your META-INF/MANIFEST.MF of your deployement and add:

Dependencies: org.hornetq

into this file.

[jfisherdev]

I tried this and it did not work.

If this is to control class loading behavior for the deployment, which is what I understand this manifest attribute to be for, I already have defined this module as a global module, so it would not be necessary [although this may be better for portability].

Does this manifest attribute have some other purpose in this case?

[jfisherdev]

At this time, the best solution appears to be to have a wait/retry mechanism on the JNDI lookup as suggested.

I appreciate the prompt responses to my question(s).

[jbertram]

It's only for classloading.  It won't have any impact on the runtime dependency issue.