WildFly JNDI Concepts: Difference between revisions
| (27 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
* [[WildFly JNDI]] | * [[WildFly JNDI]] | ||
=Enterprise Naming Context (ENC)= | |||
The Enterprise Naming Context (ENC) and application component environment are terms that can be used interchangeably. | |||
Each JEE component has an enterprise naming context (ENC). The default value is "java:comp/env". The container binds various resources into a component's ENC during deployment, using ''relative names''. | |||
=JNDI Namespaces= | |||
===java:=== | |||
==JNDI JEE Namespaces== | |||
===java:global=== | |||
The "java:global" JNDI namespace is the portable way of finding JEE components (EJBs) in the JNDI space of an application server instance, even if the components belong to another applications. For example, the following naming scheme applies to EJBs (for more details on the naming scheme see [[EJB_Concepts#EJB_and_JNDI|EJB and JNDI]]: | |||
<pre> | |||
java:global[/<application-name>]/<module-name>/<distinct-name>/<bean-name>[!<view-class-name>]?stateful | |||
</pre> | |||
Note that "java:global" does not seem to work to look up ''remote'' EJBs, meaning EJBs deployed on other application server instances. On JBoss, a name space that seems to work for that is "[[#ejb:|ejb:]]". For more details on finding and invoking remote EJBs, see [[EJB_Concepts#Remote_EJB|Invoking into Remote EJBs]] and [[Session EJB and Servlet on Different JBoss Instances|Session EJB and Servlet on Different JBoss Instances Example]]. | |||
===java:app=== | |||
The "java:app" namespace is used to look up ''local'' components (EJBs) packaged within the same application (EAR file containing multiple modules). JNDI addresses using the java:app namespace are of the following form: | |||
<pre> | |||
java:app[/<module-name>]/<bean-name>/[<view-class-name>] | |||
</pre> | |||
====java:app/env==== | |||
===java:module=== | |||
The "java:module" namespace is used to look up ''local'' components (EJBs) within the same module. "module" in this context refers to JEE module, and not JBoss module. JNDI addresses using the "java:module" namespace are of the following form: | |||
<pre> | |||
java:module/<bean-name>/[<view-class-name>] | |||
</pre> | |||
====java:module/env==== | |||
===java:comp=== | |||
====java:comp/env==== | |||
The component's [[#Enterprise_Naming_Context_.28ENC.29|ENC (Enterprise Naming Context)]]. | |||
===java:jboss/exported=== | |||
Only components that are registered within the java:jboss/exported/ namespace are remote accessible via the naming service. EJB JNDI names are registered in this scope to be made available remotely. | |||
===ejb:=== | |||
For an example of why this is essential, see [[Session_EJB_and_Servlet_on_Different_JBoss_Instances#Use_a_Specific_JNDI_Name|Session EJB and Servlet on Different JBoss Instances Example]]. | |||
=JNDI and Remoting= | =JNDI and Remoting= | ||
| Line 9: | Line 68: | ||
=Exporting for access by Remote JNDI Clients= | =Exporting for access by Remote JNDI Clients= | ||
If an object registered | If an object registered in 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". | For example, a JMS queue registered under "java:jboss/exported/jms/queue/TestQueue" can be looked up remotely as "jms/queue/TestQueue". | ||
| Line 17: | Line 76: | ||
{{Internal|WildFly_Naming_Subsystem_Configuration#.3Cremote-naming.3E|How to Activate the Remoting Naming Server}} | {{Internal|WildFly_Naming_Subsystem_Configuration#.3Cremote-naming.3E|How to Activate the Remoting Naming Server}} | ||
=Declaring an External JNDI Context= | =External JNDI Context= | ||
An ''external JNDI context'' is a JNDI context exported by a remote JNDI server that is mapped into the local JNDI namespace. External contexts are declared using the <tt><external-context></tt> element in the "naming" subsystem configuration. | |||
<font color=red> | |||
* Does a JNDI object need to be declared in ../exported/.. on the remote server to be accessible, or any object can be accessible? Experiment. | |||
* Can I make a note saying that the entire .../exported space is the "JNDI context exported by the remote JNDI server"? | |||
</font> | |||
==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 | An external JNDI Context exported by a remote JNDI server can be "imported" and exposed as part of the local JNDI namespace. The external JNDI Context has to be explicitly exported by the remote JNDI server, as described in "[[#Exporting_for_access_by_Remote_JNDI_Clients|Exporting for access by Remote JNDI Clients]]". Once exported by the remote JNDI server, the JNDI Context can be declared an "<external-context>" in the naming subsystem configuration and made accessible as part of the local JNDI namespace. Configuration details are available here: | ||
{{Internal|WildFly_Naming_Subsystem_Configuration#Importing_an_External_JNDI_Context|Importing an External JNDI Context}} | |||
=Remote Programmatic JNDI Access= | =Remote Programmatic JNDI Access= | ||
{{Internal|WildFly Remote Programmatic JNDI Access|Remote Programmatic JNDI Access}} | {{Internal|WildFly Remote Programmatic JNDI Access|Remote Programmatic JNDI Access}} | ||
=HA JNDI= | =HA JNDI= | ||
Latest revision as of 21:13, 21 September 2017
Internal
Enterprise Naming Context (ENC)
The Enterprise Naming Context (ENC) and application component environment are terms that can be used interchangeably.
Each JEE component has an enterprise naming context (ENC). The default value is "java:comp/env". The container binds various resources into a component's ENC during deployment, using relative names.
JNDI Namespaces
java:
JNDI JEE Namespaces
java:global
The "java:global" JNDI namespace is the portable way of finding JEE components (EJBs) in the JNDI space of an application server instance, even if the components belong to another applications. For example, the following naming scheme applies to EJBs (for more details on the naming scheme see EJB and JNDI:
java:global[/<application-name>]/<module-name>/<distinct-name>/<bean-name>[!<view-class-name>]?stateful
Note that "java:global" does not seem to work to look up remote EJBs, meaning EJBs deployed on other application server instances. On JBoss, a name space that seems to work for that is "ejb:". For more details on finding and invoking remote EJBs, see Invoking into Remote EJBs and Session EJB and Servlet on Different JBoss Instances Example.
java:app
The "java:app" namespace is used to look up local components (EJBs) packaged within the same application (EAR file containing multiple modules). JNDI addresses using the java:app namespace are of the following form:
java:app[/<module-name>]/<bean-name>/[<view-class-name>]
java:app/env
java:module
The "java:module" namespace is used to look up local components (EJBs) within the same module. "module" in this context refers to JEE module, and not JBoss module. JNDI addresses using the "java:module" namespace are of the following form:
java:module/<bean-name>/[<view-class-name>]
java:module/env
java:comp
java:comp/env
The component's ENC (Enterprise Naming Context).
java:jboss/exported
Only components that are registered within the java:jboss/exported/ namespace are remote accessible via the naming service. EJB JNDI names are registered in this scope to be made available remotely.
ejb:
For an example of why this is essential, see Session EJB and Servlet on Different JBoss Instances Example.
JNDI and Remoting
See
Exporting for access by Remote JNDI Clients
If an object registered in 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:
External JNDI Context
An external JNDI context is a JNDI context exported by a remote JNDI server that is mapped into the local JNDI namespace. External contexts are declared using the <external-context> element in the "naming" subsystem configuration.
- Does a JNDI object need to be declared in ../exported/.. on the remote server to be accessible, or any object can be accessible? Experiment.
- Can I make a note saying that the entire .../exported space is the "JNDI context exported by the remote JNDI 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 namespace. The external JNDI Context has to be explicitly exported by the remote JNDI server, as described in "Exporting for access by Remote JNDI Clients". Once exported by the remote JNDI server, the JNDI Context can be declared an "<external-context>" in the naming subsystem configuration and made accessible as part of the local JNDI namespace. Configuration details are available here:
Remote Programmatic JNDI Access
HA JNDI
TODO
What does this mean? remoting://host1:4447,host2:4547