JBoss 7.4 ActiveMQ Artemis Queue Can't binding to a specific JNDI name

I'm working on a JBoss migration from EAP 6.4 to 7.4. One of the issues found is the replacement of HornetQ with ActiveMQ Artemis version 2.16.0.redhat-00022. My issue in specific is the JNDI binding for the created queues.

On HornetQ the following code was used to create the queue:

import org.hornetq.api.jms.management.JMSServerControl;
...
...
JMSServerControl srv_c = getJMSServerControl(); // this method gets the object from MBServer
srv.createQueue("MyQName", "queue/MyQName", null, false);

In the other part of the code, I'm able to search the queue via JNDI name:

import javax.jms.Queue;
...
...
ctx = new InitialContext();
Queue ourQueue = (Queue) ctx.lookup("queue/MyQName");
if(ourQueue == null) {
  log.error("Queue not found!");
} else {
  log.info("Queue found");
}

Looking for an equivalent on Artemis I tried to use ActiveMQServerControl and specify the configuration for the queue creation.

import org.apache.activemq.artemis.api.core.management.ActiveMQServerControl;
...
...
ActiveMQServerControl srv_c = getJMSServerControl(); // also found via MBServer
String queueConfig = "{" +
  "\"name\": \"MyQName\"," +
  "\"address\": \"jms.queue.MyQName\"," +
  "\"durable\": false," +
  "\"entries\": [\"java:/queue/MyQName\"]" +
  "}";
srv_c.createQueue(queueConfig);

However, when I try to find the queue via JNDI it always returns that the object doesn't exist. Across the system the queues are retrieved via JNDI which is why I need to do it this way.

The JSON you're passing to ActiveMQServerControl.createQueue contains "entries" which is not valid. See the JavaDoc for QueueConfiguration for details on what properties are valid.

That said, you almost certainly should be using one of the WildFly Management Clients instead of trying to work directly with the embedded instance of ActiveMQ Artemis. By using WildFly management you'll have access to a rich model, including all the necessary JMS related operations (including adding a queue). Furthermore, those changes will be reflected in the model which provides benefits like automatically updating the XML configuration file (e.g. standalone-full.xml) on disk.

It's important to note that in this context WildFly itself manages the JNDI entries, not ActiveMQ Artemis. That's why when you look up JMS admin objects in WildFly you use org.wildfly.naming.client.WildFlyInitialContextFactory rather than a class from ActiveMQ Artemis.