The HornetQ subsystem allows for defining jms-topic(s) and jms-queus(s) for a hornetq-server. The jms-topic(s) and jms-queue(s) allow for JNDI names to be specified for each of those JMS destinations. For each of these jms-topic(s) and jms-queues(s) the HornetQ subsystem does the following:

• Set up JMSTopicService and JMSQueueService depending on the destination type.
• These services in their start method use HornetQ APIs to create the destinations. Note that JNDI binding of these destinations is not
  done at this point via the HornetQ APIs and instead (is rightly) left for the (WildFly) BinderService(s) to take care off.
• The getValue() method of these services return the Topic/Queue that was created by the services' start using HornetQ API

• For each of the destinations, the HornetQ subsystem sets up a BinderService each for the JNDI names specified for those destinations. The BinderService is configured to fetch the bound value via the JMSTopicService/JMSQueueService (i.e. they use ValueManagedReferenceFactory which ultimately ends up in a call to getValue() of those services).

Looks fine, except that the BinderService(s) have not been setup to "depend" on the JMSTopicService/JMSQueueService.

As a result, in theory (and I suspect in reality here https://developer.jboss.org/thread/259981?start=0&tstart=0) JNDI lookups for the topic/queue (even when proper dependencies are setup between the deployments and the BinderService) can end up returning null values, since although the BinderService is up and running, the backing JMSTopicService or JMSQueueService which are responsible for providing the bound value are not yet started and the topic/queue hasn't yet been created.

P.S: I don't have a way to reproduce this, since it all depends on the service startup timings. I however do suspect that this is what is causing those issues in that thread.