WildFly JNDI Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 21: Line 21:
An external JNDI Context exported by a remote JNDI server can be "imported" and exposed as part of the local JNDI name.  
An external JNDI Context exported by a remote JNDI server can be "imported" and exposed as part of the local JNDI name.  


The external JNDI Context has to be explicitly exported by the remote JNDI server, as described here: "[[Exporting for access by Remote JNDI Clients]]".
The external JNDI Context has to be explicitly exported by the remote JNDI server, as described here: "[[#Exporting_for_access_by_Remote_JNDI_Clients|Exporting for access by Remote JNDI Clients]]".


=Remote Programmatic JNDI Access=
=Remote Programmatic JNDI Access=

Revision as of 17:45, 3 April 2017

Internal

JNDI and Remoting

See

EAP 7 Note Concerning Remoting

Exporting for access by Remote JNDI Clients

If an object registered to JNDI is supposed to be looked up by remote (running in different JVM) JNDI clients, then the object must be registered under the "java:jboss/exported" JNDI context. When it is looked up remotely, the "java:jboss/exported" prefix must be omitted.

For example, a JMS queue registered under "java:jboss/exported/jms/queue/TestQueue" can be looked up remotely as "jms/queue/TestQueue".

This is made possible by a remote naming server that exposes this namespace over remoting. The remote naming server has to be explicitly activated in configuration:

How to Activate the Remoting Naming Server

Declaring an External JNDI Context

An external JNDI Context exported by a remote JNDI server can be "imported" and exposed as part of the local JNDI name.

The external JNDI Context has to be explicitly exported by the remote JNDI server, as described here: "Exporting for access by Remote JNDI Clients".

Remote Programmatic JNDI Access

Remote Programmatic JNDI Access


HA JNDI

TODO

What does this mean? remoting://host1:4447,host2:4547