📄 context.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN""http://www.w3.org/TR/REC-html40/frameset.dtd"><!--NewPage--><HTML><HEAD><!-- Generated by javadoc on Thu Apr 27 23:37:18 PDT 2000 --><TITLE>Java 2 Platform SE v1.3: Interface Context</TITLE><LINK REL ="stylesheet" TYPE="text/css" HREF="../../stylesheet.css" TITLE="Style"></HEAD><BODY BGCOLOR="white"><!-- ========== START OF NAVBAR ========== --><A NAME="navbar_top"><!-- --></A><TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0"><TR><TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1"><A NAME="navbar_top_firstrow"><!-- --></A><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3"> <TR ALIGN="center" VALIGN="top"> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD> <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="class-use/Context.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../index-files/index-1.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD> <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD> </TR></TABLE></TD><TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM><b>Java<sup><font size=-2>TM</font></sup> 2 Platform<br>Std. Ed. v1.3</b></EM></TD></TR><TR><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> PREV CLASS <A HREF="../../javax/naming/Name.html"><B>NEXT CLASS</B></A></FONT></TD><TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2"> <A HREF="../../index.html" TARGET="_top"><B>FRAMES</B></A> <A HREF="Context.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD></TR><TR><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2"> SUMMARY: INNER | <A HREF="#field_summary">FIELD</A> | CONSTR | <A HREF="#method_summary">METHOD</A></FONT></TD><TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">DETAIL: <A HREF="#field_detail">FIELD</A> | CONSTR | <A HREF="#method_detail">METHOD</A></FONT></TD></TR></TABLE><!-- =========== END OF NAVBAR =========== --><HR><!-- ======== START OF CLASS DATA ======== --><H2><FONT SIZE="-1">javax.naming</FONT><BR>Interface Context</H2><DL><DT><B>All Known Subinterfaces:</B> <DD><A HREF="../../javax/naming/directory/DirContext.html">DirContext</A>, <A HREF="../../javax/naming/event/EventContext.html">EventContext</A>, <A HREF="../../javax/naming/event/EventDirContext.html">EventDirContext</A>, <A HREF="../../javax/naming/ldap/LdapContext.html">LdapContext</A></DD></DL><DL><DT><B>All Known Implementing Classes:</B> <DD><A HREF="../../javax/naming/InitialContext.html">InitialContext</A></DD></DL><HR><DL><DT>public interface <B>Context</B></DL><P>This interface represents a naming context, which consists of a set of name-to-object bindings. It contains methods for examining and updating these bindings. <p> <h4>Names</h4> Each name passed as an argument to a <tt>Context</tt> method is relative to that context. The empty name is used to name the context itself. A name parameter may never be null. <p> Most of the methods have overloaded versions with one taking a <code>Name</code> parameter and one taking a <code>String</code>. These overloaded versions are equivalent in that if the <code>Name</code> and <code>String</code> parameters are just different representations of the same name, then the overloaded versions of the same methods behave the same. In the method descriptions below, only one version is fully documented. The second version instead has a link to the first: the same documentation applies to both. <p> For systems that support federation, <tt>String</tt> name arguments to <tt>Context</tt> methods are composite names. Name arguments that are instances of <tt>CompositeName</tt> are treated as composite names, while <tt>Name</tt> arguments that are not instances of <tt>CompositeName</tt> are treated as compound names (which might be instances of <tt>CompoundName</tt> or other implementations of compound names). This allows the results of <tt>NameParser.parse()</tt> to be used as arguments to the <tt>Context</tt> methods. Prior to JNDI 1.2, all name arguments were treated as composite names.<p> Furthermore, for systems that support federation, all names returned in a <tt>NamingEnumeration</tt> from <tt>list()</tt> and <tt>listBindings()</tt> are composite names represented as strings. See <tt>CompositeName</tt> for the string syntax of names.<p> For systems that do not support federation, the name arguments (in either <tt>Name</tt> or <tt>String</tt> forms) and the names returned in <tt>NamingEnumeration</tt> may be names in their own namespace rather than names in a composite namespace, at the discretion of the service provider.<p><h4>Exceptions</h4> All the methods in this interface can throw a <tt>NamingException</tt> or any of its subclasses. See <tt>NamingException</tt> and their subclasses for details on each exception.<p><h4>Concurrent Access</h4> A 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. Multiple threads each manipulating a different Context instance need not synchronize. Note that the <A HREF="../../javax/naming/Context.html#lookup(javax.naming.Name)"><CODE><tt>lookup</tt></CODE></A> method, when passed an empty name, will return a new Context instance representing the same naming context.<p> For purposes of concurrency control, a Context operation that returns a <tt>NamingEnumeration</tt> is not considered to have completed while the enumeration is still in use, or while any referrals generated by that operation are still being followed.<p><h4>Parameters</h4> A <tt>Name</tt> parameter passed to any method of the <tt>Context</tt> interface or one of its subinterfaces will not be modified by the service provider. The service provider may keep a reference to it for the duration of the operation, including any enumeration of the method's results and the processing of any referrals generated. The caller should not modify the object during this time. A <tt>Name</tt> returned by any such method is owned by the caller. The caller may subsequently modify it; the service provider may not.<p><h4>Environment Properties</h4><p> 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.<p> 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.<p> 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.<p> 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.<p><a name=RESOURCEFILES></a><h4>Resource Files</h4><p> To simplify the task of setting up the environment required by a JNDI application, application components and service providers may be distributed along with <em>resource files.</em> A JNDI resource file is a file in the properties file format (see <A HREF="../../java/util/Properties.html#load(java.io.InputStream)"><CODE><tt>java.util.Properties</tt></CODE></A>), 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. Here is an example of a JNDI resource file: <blockquote><tt><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></tt></blockquote> The JNDI class library reads the resource files and makes the property values freely available. Thus JNDI resource files should be considered to be "world readable", and sensitive information such as clear-text passwords should not be stored there.<p> There are two kinds of JNDI resource files: <em>provider</em> and <em>application</em>. <h5>Provider Resource Files</h5> Each service provider has an optional resource that lists properties specific to that provider. The name of this resource is: <blockquote> [<em>prefix</em>/]<tt>jndiprovider.properties</tt> </blockquote> where <em>prefix</em> is the package name of the provider's context implementation(s), with each period (".") converted to a slash ("/"). For example, suppose a service provider defines a context implementation with class name <tt>com.sun.jndi.ldap.LdapCtx</tt>. The provider resource for this provider is named <tt>com/sun/jndi/ldap/jndiprovider.properties</tt>. If the class is not in a package, the resource's name is simply <tt>jndiprovider.properties</tt>. <p> <a name=LISTPROPS></a> Certain methods in the JNDI class library make use of the standard JNDI properties that specify lists of JNDI factories: <ul> <li>java.naming.factory.object <li>java.naming.factory.state <li>java.naming.factory.control <li>java.naming.factory.url.pkgs </ul> The JNDI library will consult the provider resource file when determining the values of these properties. Properties other than these may be set in the provider resource file at the discretion of the service provider. The service provider's documentation should clearly state which properties are allowed; other properties in the file will be ignored. <h5>Application Resource Files</h5> When an application is deployed, it will generally have several codebase directories and JARs in its classpath. Similarly, when an applet is deployed, it will have a codebase and archives specifying where to find the applet's classes. JNDI locates (using <A HREF="../../java/lang/ClassLoader.html#getResources(java.lang.String)"><CODE><tt>ClassLoader.getResources()</tt></CODE></A>) all <em>application resource files</em> named <tt>jndi.properties</tt>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -