Artemis supports the HornetQ "core" protocol so all your existing HornetQ applications should work out-of-the-box from that perspective.
However, JNDI is a different matter since the JNDI implementation has changed. As you noted, Artemis doesn't use a server-side JNDI implementation (e.g. JNP). It uses a client-side implementation instead (very similar to ActiveMQ 5.x). You don't necessarily need to directly instantiate your JMS admin objects (i.e. destinations & connection factories). You can still use JNDI. You'll just need to configure the JNDI context differently than before and include the artemis-jms-client.jar on your classpath so you can use the org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory. It is definitely possible to integrate Artemis with a traditional server-side JNDI implementation. Wildfly does this already with the latest releases (which include Artemis). However, you would still need to change your client's JNDI configuration and include a new jar on the client's classpath to use the Wildfly initial context factory. To be clear, JNDI implementations are meant to be pluggable which is one reason that the externalized jndi.properties files is supported by all implementations. Hopefully you've written your applications with this in mind to ease migration. Justin ----- Original Message ----- From: "Pascal Gillet" <pascalgil...@ymail.com.INVALID> To: users@activemq.apache.org Sent: Wednesday, December 14, 2016 4:52:39 AM Subject: Migrate from HornetQ to ActiveMQ Artemis Hi Folks, We have a bunch of legacy apps that send/receive messages using JMS with HornetQ 2.4.0. We wonder to what extent it is possible to migrate the HornetQ server to ActiveMQ Artemis, ideally without changing anything other than the configuration of these applications. Our JMS clients typically include hornetq-core-client.jar, hornetq-commons.jar, netty.jar, hornetq-jms-client.jar and jboss-jms-api.jar on the classpath. We look up the JMS resources (that's JMS Queue, Topic, and ConnectionFactory instances) from the JNDI server co-located with the HornetQ standalone server (to do that, we also need the jnp-client.jar on the client classpath). The use of JNDI API along with JMS to make available the JMS objects is purely a convention. As far as I understand, Artemis (at least in standalone mode) chose to not have a JNDI server, and instead advocates for the direct instantiation of JMS Queue, Topic and ConnectionFactory instances. Does it mean that only HornetQ 2.4 clients that do not use JNDI at all and directly instantiate these objects are supported out of the box? I saw some test cases under /tests/extra-tests/protocols/hornetq that tend to demonstrate it. Artemis still provides "a client-side JNDI implementation that relies on special properties set in the environment to construct the appropriate JMS objects. In other words, no objects are stored in JNDI on the Artemis server, instead they are simply instantiated on the client based on the provided configuration." Therefore, and for the purpose of modifying only the JNDI configuration, we still must change the HornetQ jars to artemis-jms-client.jar, at least to look up the JMS connection factory ActiveMQInitialContextFactory, right!? Finally, is it possible to integrate Artemis with a JNDI server (for instance, within an application server like Wildfly)? We would declare some queues and topics in the broker.xml and make them available via the JNDI API. In this case, how to make Artemis aware of the JNDI server? In this case, we would have nothing to change on the client side, right!? Thanks for your support, Pascal GILLET
