Java EE applications often require access to a variety of resources such as databases, JMS services, and so on. In contrast to Java EE applications, a specific resource is an object that can provide a connection to a database server or a JMS messaging system. Each resource has a unique name for the identity, which is the jndi name.
JNDI (Java naming and Directoryinterface) is the standard interface for Java naming services. Starting with the Java EE 7 standard system, Jndi has become an integral part of javase, provided to applications in the form of naming and directory services .
In the Java EE server, where resources are first configured in the server's container and then distributed by naming the resource and its Jndi naming with the directory service, the Java EE application does not have to take into account the specific types and configuration parameters of the repository, as long as the corresponding resources can be found by Jndi naming. And then access the specific resources. Jndi provides a unified, loosely coupled way of locating and accessing resources for Java EE applications.
1. Jndi namespaces
Obviously, the prerequisite for applying access to resources is that the required resources must first be found through Jndi naming, and the Jndi naming must conform to a uniform naming convention. To differentiate the scope of Jndi naming, the naming and directory service divides Jndi-named environment contexts into several namespaces, adding resources and their jndi names to namespaces in the form of "name/object", thereby enabling Jndi publishing of resources and supply of lookup access.
Java EE provides the following 4 standard namespaces:
Java:comp, a valid namespace within the current component scope, such as the default JDBC data source provided by the server, the default JMS connection factory, and so on
Java:module, a valid namespace Java:app within the scope of the current class library module, a valid namespace in the current application scope Java:global, a valid namespace throughout the server scope
In addition to the 4 standard namespaces mentioned above, Wildfly also provides the following 2 namespaces, which are valid across the server:
java:/Java:jboss
Where the namespace that is available for remote Jndi access is the Java:jboss subspace java:jboss/exported.
2. The Wildfly server provides the following 4 ways to publish Jndi naming:
Using the <env-entry> element in the Web.xml file to configure the naming subsystem in the Standalone.xml file uses the standard Jndi API to combine Wildfly modules/with the standard Jndi API Extensions API
3.JNDI named Lookup
Java EE applications find Jndi naming in a variety of ways, specific can be divided into local (server) lookup and on the remote (server) lookup.
1 for local Jndi naming lookups, Wildfly provides the following 3 options:
Resource injection, such as @resource (lookup= "...") standard Jndi APIs, such as New InitialContext (). Lookup ("..."); Http-remoting JNDI lookup, such as Env.put (Context.provider_url, "http-remoting://localhost:8080");
Note that for the third way, since Wildfly no longer supports ports such as remoting Port (4447), but only one HTTP port (default 8080), the URL for a jndi named lookup is also from remote:// The localhost:4447 form becomes http-remoting://localhost:8080.
2 for remote Jndi named lookup, use JNP to find the Jndi name before JBoss as 7 (not included), but is given up by JBoss as 7 because of the large granularity of security control. JBoss as 7 provides the following 2 ways to find remote Jndi naming:
The EJB client API, which is optimized for lookup for stateless EJBs for example:
Env.put (context.url_pkg_prefixes, "org.jboss.ejb.client.naming");
(myremoteinterface) remotecontext.lookup ("Ejb:myapp/myejbjar/myejbname\!com.test.myremoteinterface");
(mystatefulremoteinterface) remotecontext.lookup ("ejb:myapp/myejbjar/mystatefulname\! Comp.test.mystatefulremoteinterface?stateful ");
Jboss-remote-naming (not recommended for EJB)
For example:
Env.put (Context.provider_url, "http-remoting://remoteip:8080");