How does Artemis client use JNDI to lookup resources?

In Apache's ActiveMQ Artemis documentation, there is a statement:

Apache ActiveMQ Artemis does not have a JNDI server. Rather, it uses 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 Apache ActiveMQ Artemis server, instead, they are simply instantiated on the client based on the provided configuration.

Now, I don't understand how does a client, e.g. Widlfly, connect to the standalone Artemis broker. I know there is a client library provided as a Wildfly's module, and I know to configure JMS bridge between local WF queue and remote one. But how does it know how to connect using client's JNDI server? Does it mean that by configuring standalone.xml file of Wildfly you configure JNDI names for looking up resources on Wildfly which are responsible for communication or am I missing something? What the quoted sentence has to do in Artemis' documentation then?

Solution

One of the goals of interfaces like JMS and JNDI is to relieve client applications of the burden of having to "know" anything about the underlying implementations. So, for example, an application written using JMS and JNDI can connect to any JMS compliant broker which provides a JNDI implementation. One day a standalone Java application can connect to ActiveMQ and the next day it can connect to WebLogic and all that would need to change is the configuration in jndi.properties.

Any Java application using the JMS and JNDI APIs, whether it's running standalone or in an application server like Wildfly, can connect to ActiveMQ Artemis if the JNDI configuration is correct. As long as you provide the correct JNDI configuration then it will "know" how to connect because all that knowledge is contained with the ActiveMQ Artemis JMS and JNDI implementation and is abstracted away from the application behind the interfaces.

The section you quoted from the ActiveMQ Artemis documentation is simply to explain to users that there is no network client/server communication when using its JNDI implementation. This is, for example, in contrast to Wildfly which does implement a "real" JNDI server and whose JNDI client does communicate over the network to look up objects.

Where objects are physically stored depends on what JNDI implementation you use. If you're using the Wildfly JNDI implementation then objects are stored on the server and any client communicates with the server to look up those objects. If you're using the Artemis JNDI implementation then objects are stored in the actual client-side JNDI implementation. Whether or not classes are modularized has no impact on the JNDI lookup.

Java objects stored in JNDI can be any kind of Object. The JNDI implementation doesn't care what kind of Object it is. You can store an Artemis JMS connection factory pointing to a remote Artemis broker in Wildfly's JNDI. If you have such a configuration and a JMS application in Wildfly looks up this Artemis JMS connection factory from Wildfly's JNDI then the JMS connection factory implementation itself will communicate with the remote Artemis broker.

Additional notes:

JNDI is not a protocol. It's just an API.
If you're using the Artemis JMS client in Wildfly it will certainly not be using JNDI to call objects on the remote Artemis broker. As noted previously, the Artemis JNDI implementation is client-side only. It performs no network communication whatsoever. The Artemis JMS client implementation performs network communication using its own "core" wire protocol.
ActiveMQ Artemis is most commonly used standalone so it needs its own JNDI implementation to facilitate JMS compliance.
Instructions on how to use the ActiveMQ Artemis JNDI implementation are in the documentation you cited previously.