JNDI Concepts: Difference between revisions
No edit summary |
|||
(16 intermediate revisions by the same user not shown) | |||
Line 17: | Line 17: | ||
The <tt>InitialContext</tt> corresponds to the root of the naming hierarchy. | The <tt>InitialContext</tt> corresponds to the root of the naming hierarchy. | ||
==Context Environment== | |||
JNDI applications need a way to communicate various preferences and properties that define the environment in which naming and directory services are accessed. For example, a context might require specification of security credentials in order to access the service. Another context might require that server configuration information be supplied. These are referred to as the <em>environment</em> of a context. The <tt>Context</tt> interface provides methods for retrieving and updating this environment. The environment is inherited from the parent context as context methods proceed from one context to the next. Changes to the environment of one context do not directly affect those of other contexts. | JNDI applications need a way to communicate various preferences and properties that define the environment in which naming and directory services are accessed. For example, a context might require specification of security credentials in order to access the service. Another context might require that server configuration information be supplied. These are referred to as the <em>environment</em> of a context. The <tt>Context</tt> interface provides methods for retrieving and updating this environment. The environment is inherited from the parent context as context methods proceed from one context to the next. Changes to the environment of one context do not directly affect those of other contexts. | ||
It is implementation-dependent when environment properties are used and/or verified for validity. For example, some of the security-related properties are used by service providers to "log in" to the directory. This login process might occur at the time the context is created, or the first time a method is invoked on the context. When, and whether this occurs at all, is implementation-dependent. When environment properties are added or removed from the context, verifying the validity of the changes is again implementation-dependent. For example, verification of some properties might occur at the time the change is made, or at the time the next operation is performed on the context, or not at all. | It is implementation-dependent when environment properties are used and/or verified for validity. For example, some of the security-related properties are used by service providers to "log in" to the directory. This login process might occur at the time the context is created, or the first time a method is invoked on the context. When, and whether this occurs at all, is implementation-dependent. When environment properties are added or removed from the context, verifying the validity of the changes is again implementation-dependent. For example, verification of some properties might occur at the time the change is made, or at the time the next operation is performed on the context, or not at all. | ||
Line 25: | Line 25: | ||
Any object with a reference to a context may examine that context's environment. Sensitive information such as clear-text passwords should not be stored there unless the implementation is known to protect it. | Any object with a reference to a context may examine that context's environment. Sensitive information such as clear-text passwords should not be stored there unless the implementation is known to protect it. | ||
=Resource Files= | |||
The [[#Context_Environment|environment]] may be set based on content distributed in ''resource files''. A JNDI resource file is a file in the properties file format containing a list of key/value pairs. The key is the name of the property (e.g. "java.naming.factory.object") and the value is a string in the format defined for that property. | |||
Example: | |||
<pre> | |||
java.naming.factory.object=com.sun.jndi.ldap.AttrsToCorba:com.wiz.from.Person | |||
java.naming.factory.state=com.sun.jndi.ldap.CorbaToAttrs:com.wiz.from.Person | |||
java.naming.factory.control=com.sun.jndi.ldap.ResponseControlFactory | |||
</pre> | |||
Thus JNDI resource files should be considered to be "world readable", and sensitive information such as clear-text passwords should not be stored there. | |||
==Provider Resource Files== | |||
{{External|https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html}} | |||
==Application Resource Files== | |||
When an application is initialized, JNDI locates all ''application resource files'' named <tt>jndi.properties</tt>, using <tt>ClassLoader.getResources()</tt>. In addition, if the file <i>java.home</i><tt>/lib/jndi.properties</tt> exists and is readable, JNDI treats it as an additional application resource file. All of the properties contained in these files are placed into the environment of the initial context. This environment is then inherited by other contexts. | |||
More details {{External|https://docs.oracle.com/javase/8/docs/api/javax/naming/Context.html}} | |||
=NameClassPair= | =NameClassPair= | ||
Line 173: | Line 57: | ||
=Composite and Compound Names= | =Composite and Compound Names= | ||
= | =Namespaces= | ||
==<tt>java:</tt>== | |||
==EJB Namespaces== | |||
{{Internal|EJB_Concepts#Namespaces|EJB JNDI Namespaces}} |
Latest revision as of 17:00, 24 March 2017
Internal
Context
A JNDI context consists of name-to-object bindings. The Java implementation of the context exposes an API for examining and updating these bindings. The Context instance is not guaranteed to be synchronized against concurrent access by multiple threads. Threads that need to access a single Context instance concurrently should synchronize amongst themselves and provide the necessary locking.
Context Names
Each name passed as an argument to a Context method is relative to that context. The empty name is used to name the context itself. The names can be represented as Name instances or as String instances, and both representations are equivalent.
For systems that support federation, String names represent composite names. Name arguments that are instances of CompositeName are treated as composite names, while Name arguments that are not instances of CompositeName are treated as compound names. list() return NamingEnumerations with composite names represented as strings. For more details see Composite and Compound Names.
Initial Context
The InitialContext corresponds to the root of the naming hierarchy.
Context Environment
JNDI applications need a way to communicate various preferences and properties that define the environment in which naming and directory services are accessed. For example, a context might require specification of security credentials in order to access the service. Another context might require that server configuration information be supplied. These are referred to as the environment of a context. The Context interface provides methods for retrieving and updating this environment. The environment is inherited from the parent context as context methods proceed from one context to the next. Changes to the environment of one context do not directly affect those of other contexts.
It is implementation-dependent when environment properties are used and/or verified for validity. For example, some of the security-related properties are used by service providers to "log in" to the directory. This login process might occur at the time the context is created, or the first time a method is invoked on the context. When, and whether this occurs at all, is implementation-dependent. When environment properties are added or removed from the context, verifying the validity of the changes is again implementation-dependent. For example, verification of some properties might occur at the time the change is made, or at the time the next operation is performed on the context, or not at all.
Any object with a reference to a context may examine that context's environment. Sensitive information such as clear-text passwords should not be stored there unless the implementation is known to protect it.
Resource Files
The environment may be set based on content distributed in resource files. A JNDI resource file is a file in the properties file format containing a list of key/value pairs. The key is the name of the property (e.g. "java.naming.factory.object") and the value is a string in the format defined for that property.
Example:
java.naming.factory.object=com.sun.jndi.ldap.AttrsToCorba:com.wiz.from.Person java.naming.factory.state=com.sun.jndi.ldap.CorbaToAttrs:com.wiz.from.Person java.naming.factory.control=com.sun.jndi.ldap.ResponseControlFactory
Thus JNDI resource files should be considered to be "world readable", and sensitive information such as clear-text passwords should not be stored there.
Provider Resource Files
Application Resource Files
When an application is initialized, JNDI locates all application resource files named jndi.properties, using ClassLoader.getResources(). In addition, if the file java.home/lib/jndi.properties exists and is readable, JNDI treats it as an additional application resource file. All of the properties contained in these files are placed into the environment of the initial context. This environment is then inherited by other contexts.
More details
NameClassPair
The javax.naming.NameClassPair class represents the name and the class of an object bound in JNDI into a specific context. The name is the , and the class is represented by a fully qualified class name.