Java Naming and Directory Interface1.0
This feature enables the use of Java Naming and Directory Interface (JNDI) to access server configured resources such as DataSources or JMS Connection Factories. It also allows access to Java primitives configured in the server as a jndiEntry.
Enabling this feature
To enable the Java Naming and Directory Interface 1.0 feature, add the following element declaration into your server.xml
file, inside the featureManager
element:
<feature>jndi-1.0</feature>
Examples
Bind constants into the default JNDI namespace
When you define a variable as a Java constant, you set a fixed value for it that cannot be changed. You can bind Java constants into the default JNDI namespace, which provides a simple and portable way to pass server configuration values into an application.
To bind constants into the JNDI namespace, specify the jndiEntry
element in your server.xml
file, as shown in the following example:
<jndiEntry jndiName="schoolOfAthens/defaultAdminUserName" value="plato" />
In this example, plato
is specified as the value for the schoolOfAthens/defaultAdminUserName
object. This constant is available to an application at run time through the JNDI namespace.
You can look up constants by calling the dolookup()
method in your application code, as shown in the following example:
String defaultAdminUserName = InitialContext.doLookup("schoolOfAthens/defaultAdminUserName");
In this example, the dolookup()
method returns the value of the schoolOfAthens/defaultAdminUserName
object to the application. As specified in the previous example, that value is the string plato
.
The type of the object is determined by interpreting the value that is stored in the jndiEntry
element as a Java literal string or primitive data type. If the parsing fails, the exact value is provided as an unmodified string. For more information, see the java.lang.Object class.
The jndiEntry
element supports the integer, floating-point, boolean, character, and string literals as described in Java Language Specification, Java SE 17 Edition, section 3.10. String and character literals might contain unicode escaped sequences, and the octal and character escape sequences. Null literals and class literals are not supported.
The following examples show Java literals.
The string "Hello, world" followed by a newline character:
<jndiEntry jndiName="a" value='"Hello, world.\n"' />
The integer with a binary value 1010101:
<jndiEntry jndiName="b" value="0b1010101" />
The single character 'X':
<jndiEntry jndiName="c" value="'X'" />
The double-precision floating point number 1.0:
<jndiEntry jndiName="d" value="1.0D" />
Bind URLs into the JDNI namespace
You can bind an instance of the Java URL class into the JNDI namespace to connect an application on the server with a resource on the internet. To bind an instance of the java.net.URL
class into the JNDI namespace, specify the jndiURLEntry
element in your server.xml
file, as shown in the following example:
<jndiURLEntry jndiName="urls/openLiberty" value="https://www.openliberty.io" />
In this example, the namespace supplies the https://www.openliberty.io
URL as the value for the openLiberty
java.net.URL
class.
Provide programmatic access to predefined variables
Open Liberty recognizes a number of predefined variables for values and directory locations in the server configuration. You can bind the values for these variables into the JNDI namespace by specifying the jndiEntry
configuration element in the server.xml
file, as shown in the following example:
<jndiEntry jndiName="serverName" value="${wlp.server.name}"/>
In this example, the predefined ${wlp.server.name}
value can be programmatically accessed from the JNDI namespace as serverName
.
To access these entries, you can use a JNDI lookup with any code that runs in the server, for example, applications, shared libraries, or features. In the following example, the dolookup()
method returns the value of the serverName
object by resolving the value of the predefined ${wlp.server.name}
variable:
Object serverName = new InitialContext.doLookup("serverName");
For more information about Open Liberty predefined variables, see Variable substitution precedence.
Developing a feature that depends on this feature
If you are developing a feature that depends on this feature, include the following item in the Subsystem-Content
header in your feature manifest file.
com.ibm.websphere.appserver.jndi-1.0; type="osgi.subsystem.feature"