目次 | 前へ | 次へ |
JNDI API は、次の 4 つのパッケージに含まれています。
JNDI サービスプロバイダインタフェースは、次の 1 つのパッケージに含まれています。
以降のセクションでは、JNDI API の概要について説明します。API についての詳細は、対応する javadoc ドキュメントを参照してください。
javax.naming
1(例外クラスは示していません)
Context
は、ネーミングコンテキストを指定するコアインタフェースです。名前からオブジェクトへのバインディングの追加、指定された名前にバインドされているオブジェクトの検索、バインディングの一覧表示、名前からオブジェクトへのバインディングの削除、同じ型のサブコンテキストの作成および破棄などの基本操作が定義されます。
public interface Context { public Object lookup(Name name) throws NamingException; public void bind(Name name, Object obj) throws NamingException; public void rebind(Name name, Object obj) throws NamingException; public void unbind(Name name) throws NamingException; public void rename(Name old, Name new) throws NamingException; public NamingEnumeration listBindings(Name name) throws NamingException; ... public Context createSubcontext(Name name) throws NamingException; public void destroySubcontext(Name name) throws NamingException; ... };
Context
内のどのネーミングメソッドも、名前を引数として取ります。各メソッドで定義されている操作は、その名前を暗黙的に解決することによって取得された Context
オブジェクトに対して実行されます。この名前が空 ("") である場合、その操作はコンテキスト自体で直接実行されます。オブジェクトの名前を合成名にして、オブジェクトの参照で使用される名前空間の配置を反映できます。クライアントは、ネームサービスの実装には公開されません。また、新しい型のネームサービスを導入するときに、アプリケーションを変更したり、実行中のアプリケーションを中断する必要はありません。
JNDI で使用される名前は、すべてコンテキストに対する相対名です。「絶対名」の概念はありません。アプリケーションは、InitialContext
クラスのその最初のコンテキストを取得することによってブートストラップできます。
public class InitialContext implements Context { public InitialContext()...; ... }
初期コンテキストには、クライアントを、URL の名前空間や DNS のルートなどの 1 つまたは複数のネーミングシステムの役立つ共有コンテキストに接続するさまざまなバインディングが含まれています。
Name
インタフェースは、ジェネリック名 (コンポーネントの順序付けられたシーケンス) を表します。Name
引数を取る各 Context
メソッドには、代わりに String
としての名前を取る対応するメソッドがあります。Name
を使用しているバージョンは、名前の合成やコンポーネントの比較など、名前を操作する必要があるアプリケーションに役立ちます。String
を使用しているバージョンは、単純に名前を読み込んだり、対応するオブジェクトを検索したりする単純なアプリケーションにより役立つ可能性があります。String
名前パラメータは、合成名を表します。Name
パラメータでも、合成名または複合名を使用できます。
CompositeName
クラスは、複数の名前空間の名前 (基本名または複合名) のシーケンスを表します。Context
クラスのメソッドに指定された Name
パラメータが CompositeName
のインスタンスである場合、その名前は合成名を表します。
Context
クラスのメソッドに指定された Name
パラメータが CompositeName
のインスタンスでない場合、その名前は、CompoundName
クラスまたはその他の何らかの実装クラスで表すことのできる複合名を表します。CompoundName
クラスは、1 つの名前空間の階層名を表します。コンテキストの名前パーサーは、特定のコンテキストに関連付けられた構文に基づいて、複合名を操作するときに使用します。
public interface Context {
...
public NameParser getNameParser(Name name) throws NamingException;
...
}
このレベルでの名前の構文的な操作が必要になる可能性があるアプリケーションの種類の例として、名前空間ブラウザがあります。その他のほとんどのアプリケーションでは、文字列または合成名が使用されます。
Context.lookup()
は、もっとも一般的に使用される操作です。このコンテキストの実装は、Java アプリケーションに必要なクラスのオブジェクトを返すことができます。たとえば、クライアントがプリンタの名前を使用して対応する Printer
オブジェクトを検索したあと、そこに直接印刷することがあります。
Printer printer = (Printer) ctx.lookup("treekiller"); printer.print(report);
Context.listBindings()
は、名前からオブジェクトへのバインディングの列挙を返します。各バインディングは、Binding
クラスのオブジェクトで表されます。バインディングは、バインドされたオブジェクトの名前、オブジェクトのクラスの名前、およびオブジェクト自体で構成されます。
Context.list()
メソッドは listBindings()
に似ていますが、NameClassPair
オブジェクトの列挙を返す点が異なります。各 NameClassPair
には、オブジェクトの名前と、そのオブジェクトのクラスの名前が含まれています。list()
メソッドは、コンテキスト内でバインドされたオブジェクトに関する情報を検出しようとするブラウザなどのアプリケーションに役立ちますが、実際のオブジェクトがすべて必要なわけではありません。listBindings()
は同じ情報のすべてを提供しますが、操作の負荷がはるかに大きくなる可能性があります。
public class NameClassPair ... { public String getName() ...; public String getClassName() ...; ... } public class Binding extends NameClassPair { public Object getObject() ...; ... }
Context
の実装ごとに、異なる種類のオブジェクトをネイティブにバインドできます。すべての汎用のコンテキスト実装でサポートすべき特に役立つオブジェクトとして、Reference
クラスがあります。ディレクトリの外部のオブジェクトは、参照によって表現されます。参照を使用すれば、JNDI クライアントから、X.500 などのネームサービスまたはディレクトリサービスに対して、事実上任意のクラスのオブジェクトをバインドできます。Java プログラミング言語で作成されたオブジェクトが、そのサービスでネイティブにサポートされている必要はありません。
Context.lookup()
や Binding.getObject()
などの操作の結果が Reference
オブジェクトである場合、JNDI はこの参照をクライアントに返す前に、それが表すオブジェクトに変換しようとします。この特に重要な例が、あるネーミングシステムの Context
を表す参照が別のネーミングシステム内の名前にバインドされている場合に発生します。参照によって、複数の互いに依存しないネームサービスが結合され、JNDI の合成名前空間が構築されます。このメカニズムについての詳細は、JNDI SPI のドキュメントを参照してください。
参照で表すことのできるオブジェクトでは、Referenceable
インタフェースが実装されていなければなりません。その 1 つのメソッドである getReference()
は、そのオブジェクトの参照を返します。このオブジェクトが任意のコンテキストの名前にバインドされているときに、そのオブジェクトをネイティブに格納できない場合は、コンテキスト実装ではその参照を配下のシステムに格納します。
各参照には、それが表すオブジェクトのクラスの名前が含まれている可能性があり、またそのオブジェクトのクラスファイルを見つけることのできる位置 (通常は URL) も含まれている可能性があります。さらに、参照には、RefAddr
クラスのオブジェクトのシーケンスが含まれています。各 RefAddr
には、さらに「型」の文字列と何らかのアドレス指定データ (一般には、文字列またはバイト配列) が含まれています。
JNDI 名前空間に「シンボリック」リンクを追加するには、LinkRef
と呼ばれる特殊な Reference
を使用します。このクラスには、JNDI オブジェクトの名前が含まれています。シンボリックリンクは、デフォルトでは、JNDI の名前が解決されたときに評価されます。
一部のネームサービスまたはディレクトリサービスは、クライアントの要求を別のサーバーにリダイレクトするための照会の概念をサポートしています。JNDI クライアントでは、その照会の自動的な追跡、無視、または手動処理を要求できます。
抽象クラス ReferralException
は、照会を表すために使用されます。
public abstract class ReferralException extends NamingException { public abstract Context getReferralContext() throws NamingException; ... public abstract Object getReferralInfo(); public abstract void retryReferral(); public abstract boolean skipReferral(); }
照会が検出され、クライアントが照会の無視も自動的な追跡も行わないように要求していた場合は、ReferralException
がスローされます。getReferralInfo()
メソッドは、照会先に関する情報を (サービスプロバイダに適した形式で) 提供します。アプリケーションはこの情報を検査する必要はありませんが、ユーザーがその照会に従うかどうかを判断できるように、その情報をユーザーに提供することを選択する可能性があります。skipReferral()
を使用すると、アプリケーションは照会を破棄し、次の照会 (存在する場合) の処理に進むことができます。
操作を続行するには、アプリケーションは元のメソッドに指定した同じ引数を使用して、照会コンテキストでこのメソッドを再度呼び出します。
javax.naming.directory
2
DirContext
インタフェースは、ディレクトリオブジェクトに関連付けられた属性を検査および更新するためのメソッドを定義することによって、ディレクトリ機能を有効にします。
public interface DirContext extends Context { public Attributes getAttributes(Name name) throws NamingException; public Attributes getAttributes(Name name, String[] attrIds) throws NamingException; ... public void modifyAttributes(Name name, int modOp, Attributes attrs) throws NamingException; public void modifyAttributes(Name name, ModificationItem[] mods) throws NamingException; ... }
ディレクトリに対して getAttributes()
操作を実行すると、その属性の一部またはすべてが返されます。属性は、2 つの形式の modifyAttributes()
を使用して変更されます。どちらの形式も、次のいずれかの「変更操作」を使用します。
ADD_ATTRIBUTE REPLACE_ATTRIBUTE REMOVE_ATTRIBUTE
ADD_ATTRIBUTE
操作が、ある属性がすでに存在する場合はその属性に値を追加するのに対して、REPLACE_ATTRIBUTE
操作は既存の値をすべて破棄します。最初の形式の modifyAttributes()
は、一連の属性の各要素に対して指定された操作を実行します。2 番目の形式は、ModificationItem
クラスのオブジェクトの配列を取得します。
public class ModificationItem { public ModificationItem(int modOp, Attribute attr) ...; ... }
各操作は、その対応する属性に対して、指定された順序で実行されます。可能な場合、コンテキスト実装は、modifyAttributes()
の各呼び出しを原子的操作として実行するようにしてください。
ディレクトリオブジェクトには、0 個以上の Attribute
オブジェクトのセットが含まれています。各属性は、文字列の識別子で識別されます。また、任意の型の値を 0 個以上指定できます。
public interface Attribute ... { ... public String getID(); public Object get(int n) throws NamingException; public boolean isOrdered(); public NamingEnumeration getAll() throws NamingException; ... }
属性の値は、順序付けても順序付けなくてもかまいません。値を順序付けていない場合は、複製は許可されません。値を順序付けた場合は、複製が許可されます。
属性は、Attributes
インタフェースを使用してコレクションにグループ化されます。
public interface Attributes ... { ... public Attribute get(String attrID); public NamingEnumeration getIDs(); public NamingEnumeration getAll(); public Attribute put(Attribute attr); public Attribute remove(String attrID); ... }
JNDI は、便宜上、2 つのインタフェース BasicAttribute
と BasicAttributes
のための実装を提供します。サービスプロバイダおよびアプリケーションでは、独自の実装を使用できます。
Attributes
や Attribute
への更新 (属性またはその値の追加や削除など) を行なっても、ディレクトリ内の対応する表現には影響を与えないことに注意してください。ディレクトリへの更新を有効にできるのは、DirContext.modifyAttributes()
を使用した場合だけです。
DirContext
インタフェースは、Context
インタフェースを拡張することによってネーミングコンテキストとしても動作します。つまり、任意のディレクトリオブジェクトからネーミングコンテキストを提供できます。さまざまなユーザー情報を保持しているディレクトリオブジェクトは、プリンタ、ファイルシステム、カレンダなど、個人にかかわるリソースの本来のネーミングコンテキストにもなります。
ハイブリッド操作では、特定のネーミングおよびディレクトリ操作を 1 つの原子的操作で実行します。
public interface DirContext extends Context { ... public void bind(Name name, Object obj, Attributes attrs) throws NamingException; ... }
提供されるその他のハイブリッド操作には、追加の Attributes
引数を受け入れる rebind()
と createSubcontext()
があります。
ディレクトリ操作を実行しているアプリケーションは、javax.naming.InitialContext
の代わりに InitialDirContext
を使用して初期コンテキストを作成できます。
public class InitialDirContext extends InitialContext implements DirContext { public InitialDirContext() ...; ... }
次に、その初期コンテキストで Context
または DirContext
インタフェースの任意のメソッドを呼び出すことができます。
DirContext
インタフェースは、ディレクトリのコンテンツベースの検索をサポートします。もっとも単純で使用頻度の高い使用法は、アプリケーションで照合のための属性セットを指定する方法です。多くの場合、属性には特定の値を指定します。この場合は、そのディレクトリオブジェクトに対して DirContext.search()
メソッドが呼び出され、これにより、一致するディレクトリオブジェクトが要求された属性とともに返されます。
public interface DirContext extends Context { ... public NamingEnumeration search(Name name, Attributes matchingAttributes) throws NamingException; public NamingEnumeration search(Name name, Attributes matchingAttributes, String[] attributesToReturn) throws NamingException; ... }
検索の結果は、SearchResult
クラスのオブジェクトの列挙を含む NamingEnumeration
として返されます。
public class SearchResult extends Binding { ... public Attributes getAttributes() ...; }
より詳細に検索する方法として、検索フィルタを指定したり、検索の範囲や結果の最大サイズなどの制御情報を指定したりすることができます。検索フィルタには、LDAP について規定されている Internet RFC 2254 に準拠した構文を指定します。SearchControls
引数は、検索の範囲として次のようなものを指定します。検索範囲には、ディレクトリ階層内の単一ディレクトリオブジェクト、すべての子、またはすべての子孫を含めることができます。
public interface DirContext extends Context { ... public NamingEnumeration search(Name name, String filter, SearchControls ctls) throws NamingException; public NamingEnumeration search(Name name, String filter, Object[] filterArgs, SearchControls ctls) throws NamingException; ... }
スキーマは、名前空間の構造とその中に格納されている属性を定義する規則を記述します。スキーマは、名前空間全体に対して単一のスキーマを作成することもできますが、属性ごとに詳細に作成することもできます。
スキーマは情報のツリーとして表現できます。このため、JNDI ですでに定義されているネーミングインタフェースおよびディレクトリインタフェースは、簡単にツリーで表現できます。アプリケーションは名前空間のスキーマ部分に統一された方法でアクセスできるため、これは強力な機能です。たとえば、ブラウザからスキーマツリーの情報にアクセスするときは、ディレクトリオブジェクトにアクセスするときと同じ方法で行うことができます。
基になるコンテキスト実装によって適切なサポートが提供される場合、アプリケーションは、ディレクトリオブジェクトに関連付けられたスキーマを取得できます。
ディレクトリオブジェクトに関連付けられたスキーマツリーのルートを取得するために DirContext.getSchema()
が使用されます。そのルートには、それぞれが説明されている種類の定義を示す、「ClassDefinition」、「AttributeDefinition」、「SyntaxDefinition」などの子が存在します。スキーマのルートとその子孫は、DirContext
型のオブジェクトです。DirContext.getSchemaClassDefinition()
メソッドは、特定のディレクトリオブジェクトに関するクラスの説明を含む DirContext
を返します。
public interface DirContext extends Context { ... public DirContext getSchema(Name name) throws NamingException; public DirContext getSchemaClassDefinition(Name name) throws NamingException; ... }
さらに、任意の属性に関連付けられたスキーマには、Attribute.getAttributeDefinition()
および getAttributeSyntaxDefinition()
メソッドを使用してアクセスできます。
public interface Attribute ... { ... public DirContext getAttributeDefinition() throws NamingException; public DirContext getAttributeSyntaxDefinition() throws NamingException; ... }
ディレクトリからスキーマへのマッピングの例は、スキーマ情報にアクセスするためのさまざまな関連付けを示す例です。
javax.naming.event
3javax.naming.event
パッケージには、ネームおよびディレクトリサービスでのイベント通知をサポートするためのクラスとインタフェースが含まれています。
NamingEvent
は、ネームサービスまたはディレクトリサービスによって生成されたイベントを表します。
public class NamingEvent extends java.util.EventObject { ... public int getType(); public Binding getOldBinding(); public Binding getNewBinding(); ... }
イベントのタイプによって、そのイベントの種類が識別されます。NamingEvent
クラスでは、次の 4 つのイベントのタイプが定義されています。
OBJECT_ADDED
OBJECT_REMOVED
OBJECT_RENAMED
OBJECT_CHANGED
イベントのタイプに加えて、NamingEvent
には、変更の前後のオブジェクトに関する情報などの、変更に関するその他の情報が含まれています。
ネーミングリスナーとは、NamingEvent
に登録されるオブジェクトのことです。これは、NamingListener
インタフェースで表されます。NamingEvent
の各カテゴリが、NamingListener
の対応するサブタイプによって処理されます。NamespaceChangeListener
インタフェースが名前空間の変更を対象とするリスナーを表すのに対して、ObjectChangeListener
は、オブジェクトの内容への変更を対象とするリスナーを表します。リスナーの実装には、関連するイベントのタイプに応じて、これらのインタフェースのどちらかまたは両方が実装されます。
EventContext
および EventDirContext
インタフェースは、イベントの登録と登録解除をサポートするために、それぞれ Context
および DirContext
インタフェースを拡張します。
public interface EventContext extends Context { ... public void addNamingListener(Name target, int scope, NamingListener l) throws NamingException; public void removeNamingListener(NamingListener l) throws NamingException; public boolean targetMustExist() throws NamingException; }
対応する Context
インタフェース内のメソッドと同様に、addNamingListener()
には、String
名前引数を受け入れるオーバーロードがあります。この名前パラメータは、ターゲットと呼ばれます。スコープパラメータには、ターゲットのオブジェクトに登録するか、ターゲットのコンテキストの直下の子に登録するか、ターゲットのオブジェクトをルートとするサブツリー全体に登録するかを指定します。
存在しないターゲットを対象として登録することも可能ですが、サービスプロバイダや基になるプロトコル/サービスでこれをサポートできる範囲が制限されることがあります。アプリケーションは、targetMustExist()
メソッドを使用して、存在しないターゲットの登録が EventContext
でサポートされているかどうかを確認できます。
public interface EventDirContext extends EventContext, DirContext { public void addNamingListener(Name target, String filter, SearchControls ctls, NamingListener l) throws NamingException; public void addNamingListener(Name target, String filter, Object[] filterArgs, SearchControls ctls, NamingListener l) throws NamingException; ... }
EventDirContext
インタフェースでは、リスナーが検索フィルタ (インターネット RFC 2254) を使用して識別されたオブジェクトを対象として登録できるようにするために、EventContext
および DirContext
インタフェースを拡張します。
対応する DirContext
インタフェース内のメソッドと同様に、addNamingListener()
メソッドには、String
名前引数を受け入れるオーバーロードがあります。
addNamingListener()
メソッドが呼び出された EventContext/EventDirContext
インスタンスは、生成されている (可能性のある) イベントのイベントソースです。登録されたリスナーが NamingEvent
で getSource()
または getEventContext()
を呼び出した場合、この EventContext
/EventDirContext
インスタンスが返されます。
NamespaceChangeListener listener = ...; src.addNamingListener("x", SUBTREE_SCOPE, listener);
そのあと、「x/y」という名前のオブジェクトが削除された場合、listener
に配信される対応する NamingEvent
(evt
) には、そのイベントソースとして src
が含まれている必要があります。次のどちらの形式でもかまいません。
evt.getEventContext() == src evt.getOldBinding().getName().equals("x/y")
リスナーがコンテキストにイベントを登録した場合、そのコンテキストは、そのイベントを生成するために必要な情報を収集するために何らかの内部処理の実行が必要になることがあります。たとえば、サーバー上の変更の対象を登録し、最終的にイベントに変換するには、コンテキストからサーバーに要求を発行する必要があります。エラーが発生したためイベントの情報を収集できない場合は、リスナーにはイベントの通知は行われません。このようなエラーが発生した場合は、リスナーに通知するために NamingExceptionEvent
がトリガーされ、そのリスナーの登録が自動的に解除されます。
ベースとなる NamingListener
インタフェースでは、このようなエラーをリスナーを通知できるように、namingExceptionThrown()
メソッドが定義されます。
public interface NamingListener extends java.util.EventListener { public void namingExceptionThrown(NamingExceptionEvent evt); }
javax.naming.ldap
4
javax.naming.ldap
パッケージには、より汎用的な javax.naming.directory
パッケージではまだサポートされていない LDAP v3 固有の機能を使用するためのクラスとインタフェースが含まれています。実際、LDAP を使用するほとんどの JNDI アプリケーションは javax.naming.directory
パッケージで十分なので、このパッケージを使用する必要はありません。このパッケージは、拡張操作、コントロール、または非要請通知を使用するアプリケーションで、主に使用します。
検索や変更などの適切に定義された操作の指定に加えて、LDAP v3 プロトコル (インターネット RFC 2251) は、LDAP クライアントとサーバーの間で未定義の操作を転送するための方法も指定します。これらの操作は、拡張操作と呼ばれます。拡張操作は、IETF などの標準化機構またはベンダーによって定義されます。
LdapContext
インタフェースは、拡張操作を実行するためのメソッドを定義します。
public interface LdapContext extends DirContext { public ExtendedResponse extendedOperation(ExtendedRequest request) throws NamingException; ... }
ExtendedRequest
インタフェースが拡張操作への引数を表すのに対して、ExtendedResponse
インタフェースは拡張操作の結果を表します。ExtendedRequest
または ExtendedResponse
は、その拡張操作を識別する識別子と、要求/応答の ASN.1 BER でエンコードされた内容を含むバイト配列で構成されています。
アプリケーションは通常、ExtendedRequest
/ExtendedResponse
インタフェースを直接には処理しません。代わりに、これらのインタフェースを実装しているクラスが処理されます。これらのクラスは、IETF によって標準化された拡張操作のレパートリの一部として取得しますが、ベンダー固有の拡張操作の場合はディレクトリベンダーから取得します。要求クラスには、型保証された簡単な方法で引数を受け取るコンストラクタが必要です。また、応答クラスには、同様の方法で応答のデータを取得するアクセスメソッドが必要です。要求および応答クラスでは、BER 値のエンコードおよびデコードが行われます。
たとえば、LDAP サーバーが「時間取得」の拡張操作をサポートしているとします。LDAP サーバーは、アプリケーションがこの機能を使用できるように GetTimeRequest
や GetTimeResponse
などのクラスを指定します。アプリケーションはこれらのクラスを次のように使います。
GetTimeResponse resp = (GetTimeResponse)lctx.extendedOperation(new GetTimeRequest()); long time = resp.getTime();
LDAP v3 プロトコル (インターネット RFC 2251) を使用すると、未定義の修飾子によって任意の要求または応答を拡張できます。これらの修飾子は、コントロールと呼ばれます。要求とともに送信されるコントロールは要求コントロールと呼ばれ、応答とともに送信されるコントロールは応答コントロールと呼ばれます。コントロールは、IETF などの標準化機構またはベンダーによって定義されます。要求コントロールと応答コントロールを対応付ける必要はありません。
JNDI では、要求コントロールが次の 2 つのカテゴリに分類されます。
接続要求コントロールは、LDAP サーバーとの接続を確立または再確立する必要がある場合は常に使用されます。コンテキスト要求コントロールは、接続以外のすべての LDAP 操作を LDAP サーバーに送信するときに使用します。2 種類のコントロールを使用するのは、JNDI が高レベルの API で、接続を直接処理できないためです。必要な接続は、サービスプロバイダで管理されます。このため、1 つの接続が複数のコンテキストインスタンスで共有されることがあります。サービスプロバイダでは、独自のアルゴリズムを使用して、接続およびネットワークの状態を保持することができます。この場合、コンテキストインスタンス上でメソッドが呼び出されたときに、サービスプロバイダは、対応する LDAP 操作以外に、接続の管理が必要になることがあります。接続を管理する場合は接続要求コントロールを使用しますが、通常の LDAP 操作の場合はコンテキスト要求コントロールを使用します。
LdapContext
インタフェースは、コントロールを処理するためのメソッドを定義します。
public interface LdapContext extends DirContext { public void reconnect(Control[] connCtls) throws NamingException; public Control[] getConnectControls() throws NamingException; ... public LdapContext newInstance(Control[] reqCtls) throws NamingException; public void setRequestControls(Control[] reqCtls) throws NamingException; public Control[] getRequestControls() throws NamingException; ... public Control[] getResponseControls() throws NamingException; }
Control
インタフェースは、コントロールを表します。このインタフェースには、コントロールを識別する識別子、および ASN.1 BER 方式でエンコードされたコントロールの内容が含まれるバイト配列で構成されます。
接続要求コントロールは、初期コンテキストコンストラクタを使用して初期化され、コンテキストから派生したコンテキストによって継承されます。コンテキストの接続要求コントロールを変更するために reconnect()
が使用されます。コンテキストの接続要求コントロールは、getConnectControls()
を使用して取得されます。
コンテキスト要求コントロールは newInstance()
を使用して初期化され、setRequestControls()
を使用して変更されます。newInstance()
は、マルチスレッドアクセスの目的で、コンテキストの新しいインスタンスを作成するための便利なメソッドです。たとえば、複数のスレッドで個別のコンテキスト要求コントロールを使用する場合は、スレッドごとにこのメソッドを使用して、コンテキストの独自のコピーの取得、およびコンテキスト要求コントロールの設定と取得を行うことができます。このとき、ほかのスレッドと同期化する必要はありません。
接続要求コントロールとは異なり、コンテキスト要求コントロールは、コンテキストから派生したコンテキストインスタンスには継承されません。派生したコンテキストインスタンスは、コンテキスト要求コントロールを使用しないで初期化されます。派生したコンテキストインスタンスの要求コントロールは、setRequestControls()
を使用して明示的に設定する必要があります。コンテキストのコンテキスト要求コントロールは、getRequestControls()
を使用して取得されます。
LDAP 拡張操作またはコントロールを実行しているアプリケーションは、javax.naming.InitialContext
または javax.naming.directory.InitialDirContext
の代わりに InitialLdapContext
を使用して初期コンテキストを作成できます。
public class InitialLdapContext extends InitialDirContext implements LdapContext { public InitialDirContext() ...; public InitialDirContext(Hashtable env, Control[] connCtls) ...; }
次に、その初期コンテキストで Context
、DirContext
、または LdapContext
インタフェースの任意のメソッドを呼び出すことができます。connCtls
引数を受け入れるコンストラクタを使用すると、アプリケーションは、LDAP サーバーとの接続を確立するときに使用されるコントロールを指定できます。
クライアントとサーバーの間の通常の要求/応答型の対話に加えて、LDAP v3 プロトコルでは、非要請通知も指定します。これは、何からのクライアント要求への応答としてではなく、サーバーからクライアントに非同期に送信されるメッセージです。
JNDI は、javax.naming.event
パッケージに組み込まれたイベントモデルを使用して非要請通知をサポートします。ここでは、UnsolicitedNotificationEvent
クラスとそれに対応する UnsolicitedNotificationListener
インタフェースが定義されます。UnsolicitedNotificationEvent
を受信するようにアプリケーションを登録するには、UnsolicitedNotificationListener
を EventContext.addNamingListener()
に指定します。