モジュール java.naming
パッケージ javax.naming

インタフェースContext

既知のすべてのサブインタフェース:
DirContext, EventContext, EventDirContext, LdapContext
既知のすべての実装クラス:
InitialContext, InitialDirContext, InitialLdapContext

public interface Context
このインタフェースは、名前からオブジェクトへのバインディングのセットから構成されるネーミング・コンテキストを表します。 このインタフェースには、これらのバインディングを検査および更新するメソッドが含まれています。

名前

Contextメソッドに引数として渡される各名前は、そのコンテキストに対して相対的です。 コンテキスト自体を指定する場合は、空の名前が使用されます。 名前パラメータはnullにできません。

ほとんどのメソッドには、NameパラメータおよびStringを使用するオーバーロードされたバージョンがあります。 これらのオーバーロードされたバージョンは、NameパラメータとStringパラメータが単に同じ名前の異なる表現である場合に、同じメソッドのオーバーロードされたバージョンが同じように動作するという点で同等です。 以下のメソッドの説明では、1つのバージョンだけが完全にドキュメント化されています。 2番目のバージョンには、最初のバージョンへのリンクがあり、同じドキュメントが両方に適用されます。

フェデレーションをサポートするシステムの場合、ContextメソッドのString名前引数はコンポジット名です。 CompositeNameのインスタンスである名前引数はコンポジット名として扱われ、CompositeNameのインスタンスではないName引数は複合名(CompoundNameのインスタンス、または複合名のその他の実装である場合があります)として扱われます。 これにより、NameParser.parse()の結果をContextメソッドの引数として使用できます。 JNDI 1.2以前は、すべての名前引数が合成名とみなされていました。

さらに、フェデレーションをサポートするシステムでは、list()およびlistBindings()からNamingEnumerationで返されるすべての名前は、文字列として表されるコンポジット名です。 名前の文字列構文については、CompositeNameを参照してください。

フェデレーションをサポートしていないシステムの場合、名前引数(NameまたはStringフォーム)およびNamingEnumerationで返される名前は、サービス・プロバイダの判断で、コンポジット・ネームスペースの名前ではなく、独自のネームスペースの名前にすることができます。

例外

このインタフェースのすべてのメソッドは、NamingExceptionまたはそのサブクラスをスローできます。 各例外の詳細は、NamingExceptionとそのサブクラスを参照してください。

並行アクセス

Contextインスタンスは、複数のスレッドによる並行アクセスに対して同期することは保証されていません。 単一のContextインスタンスに並行してアクセスする必要のあるスレッドは、それらのスレッド間で同期化し、必要なロックをする必要があります。 異なるContextインスタンスを操作する複数スレッドは、同期化される必要はありません。 lookupメソッドは、空の名前を渡すと、同じネーミング・コンテキストを表す新しいコンテキスト・インスタンスを返します。

同時実行性制御のために、NamingEnumerationを返すコンテキスト操作は、列挙がまだ使用中であるか、その操作によって生成された参照がまだ実行中である間は完了したとみなされません。

Parameters

Contextインタフェースまたはそのサブインタフェースのいずれのメソッドにも渡されるNameパラメータは、サービス・プロバイダによって変更されません。 サービス・プロバイダでは、メソッドの結果の列挙、および生成された参照の処理を含むオペレーションの間に、そこへの参照が保持されます。 呼出し側は、この間にオブジェクトを変更することはできません。 そのようなメソッドから返されるNameは、コール元によって所有されます。 呼出し側はその後このオブジェクトを変更できますが、サービス・プロバイダは変更できません。

環境プロパティ

JNDIアプリケーションでは、ネーミング・サービスとディレクトリ・サービスからアクセスされる環境を定義する、さまざまな設定やプロパティを伝達する方法が必要とされます。 たとえば、あるコンテキストでは、サービスにアクセスするためにセキュリティ資格の指定が必要になります。 別のコンテキストでは、サーバー構成情報を指定する必要があります。 これらは、コンテキストの環境と呼ばれます。 Contextインタフェースには、この環境を取得および更新するためのメソッドが用意されています。

環境は、コンテキスト・メソッドがあるコンテキストから次のコンテキストに進むにつれて、親コンテキストから継承されます。 1つのコンテキストの環境を変更しても、その他のコンテキストの環境には直接影響しません。

環境プロパティの使用、または有効性の検査、あるいはその両方がいつ行われるかは、実装に依存します。 たとえば、ディレクトリに「ログイン」するために、サービス・プロバイダでセキュリティ関連のプロパティが使用されるとします。 このログイン・プロセスは、コンテキストが作成されたとき、またはコンテキストでメソッドが最初に呼び出されたときに発生します。 これがいつ発生するか、および発生するかどうかは、実装に依存します。 コンテキストに対して環境プロパティの追加または削除が行われたときに、変更の有効性の検査が行われるタイミングも、実装に依存します。 たとえば、あるプロパティの検査は、変更が行われたとき、またはコンテキストで次のオペレーションが実行されたときに行われるか、あるいはまったく行われません。

コンテキストへの参照を含むオブジェクトでは、そのコンテキストの環境が検査されます。 クリアテキストのパスワードなどの重要な情報は、実装で保護されているかどうかがわからない場合には、保存しないでください。

リソース・ファイル

JNDIアプリケーションで必要な環境を設定するタスクを簡単にするために、アプリケーション・コンポーネントとサービス・プロバイダがリソース・ファイルとともに分配されることがあります。 JNDIリソース・ファイルは、キー/バリューのペアのリストを含むプロパティ・ファイル形式(java.util.Propertiesを参照してください)のファイルです。 キーはプロパティの名前(java.naming.factory.objectなど)で、値はそのプロパティに定義された形式の文字列です。 次に、JNDIリソース・ファイルの例を示します。

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
JNDIクラス・ライブラリでは、リソース・ファイルを読み込み、プロパティ値を自由に使用できるようにします。 JNDIリソース・ファイルは、不特定のユーザーが読み込む可能性があります。クリアテキストのパスワードなどの重要な情報は、ここに保存しないでください。

JNDIリソース・ファイルには、プロバイダおよびアプリケーションの2種類があります。

プロバイダ・リソース・ファイル

各サービス・プロバイダには、そのプロバイダに固有のプロパティをリストに表示するオプションのリソースがあります。 このリソースの名前は次のようになります。
[prefix/]jndiprovider.properties
ここで、prefixはプロバイダのコンテキスト実装のパッケージ名であり、各ピリオド(「.」)はスラッシュ(「/」)に変換されます。 たとえば、サービス・プロバイダがcom.sun.jndi.ldap.LdapCtxというクラス名を持つコンテキスト実装を定義するとします。 このプロバイダのプロバイダ・リソースには、com/sun/jndi/ldap/jndiprovider.propertiesという名前が付けられます。 クラスがパッケージに含まれていない場合、リソースの名前は単にjndiprovider.propertiesです。

JNDIクラス・ライブラリの特定のメソッドでは、JNDIファクトリのリストを指定する標準JNDIプロパティが使用されます。

  • java.naming.factory.object
  • java.naming.factory.state
  • java.naming.factory.control
  • java.naming.factory.url.pkgs
JNDIライブラリでは、これらのプロパティの値を決定するときに、プロバイダ・リソース・ファイルが参照されます。 これ以外のプロパティは、サービス・プロバイダの判断により、プロバイダ・リソース・ファイルで設定されます。 サービス・プロバイダのドキュメントでは、使用可能なプロパティが明示される必要があります。ファイルのその他のプロパティは無視されます。

アプリケーション・リソース・ファイル

アプリケーションが配置される場合、通常はclasspathに複数のコードベース・ディレクトリおよびJARがあります。 JNDIは、クラスパス内でjndi.propertiesという名前のすべての「アプリケーション・リソース・ファイル」を(ClassLoader.getResources()を使用して)として検出します。 また、Javaインストール・ディレクトリに組込みプロパティ・ファイル(通常はconf/jndi.properties)が含まれている場合、JNDIはそれを追加のアプリケーション・リソース・ファイルとして扱います。 これらのファイルに含まれるプロパティはすべて、初期コンテキストの環境に配置されます。 この環境は、他のコンテキストに継承されます。

1つ以上のアプリケーション・リソース・ファイルにあるプロパティの場合、JNDIでは検索された最初の値が使用されるか、または意味がある場合に限り、すべての値が連結されます(詳細は次に示します)。 たとえば、"java.naming.factory.object"プロパティが3つのjndi.propertiesリソース・ファイルで見つかった場合、オブジェクト・ファクトリのリストは、3つすべてのファイルのプロパティ値を連結したものです。 この方式を使用すると、配置可能なコンポーネントのそれぞれで、エクスポートするファクトリがリスト表示されます。 JNDIでは、ファクトリ・クラスを検索するときに、これらのエクスポート・リストがすべて収集および使用されます。

プロパティの検索アルゴリズム

JNDIが初期コンテキストを構築する場合、コンテキストの環境は、コンストラクタ、システム・プロパティおよびアプリケーション・リソース・ファイルに渡される環境パラメータで定義されたプロパティを使用して初期化されます。 詳細については、InitialContextを参照してください。 この初期環境は、ほかのコンテキスト・インスタンスで継承されます。

JNDIクラス・ライブラリでプロパティの値を決定する必要がある場合は、次の2つのソースから値を順にマージして実行します。

  1. 生成されるコンテキストの環境。
  2. 操作中のコンテキストのプロバイダ・リソース・ファイル(jndiprovider.properties)。
この2つのソースのプロパティについて、JNDIではプロパティの値が次のように決定されます。 プロパティが、JNDIファクトリのリストを指定する標準JNDIプロパティの1つの場合(上記にリスト表示されている)、値は1つのコロンで区切られたリストに連結されます。 ほかのプロパティの場合は、検索された最初の値だけが使用されます。

サービス・プロバイダでプロパティの値を決定する必要がある場合、通常は環境から値が直接取得されます。 サービス・プロバイダは、独自のプロバイダ・リソース・ファイルに配置される、プロバイダ固有のプロパティを定義できます。 その場合は、前の段落で説明した値をマージする必要があります。

このように、各サービス・プロバイダの開発者は、そのサービス・プロバイダで使用するファクトリのリストを指定できます。 これらは、アプリケーションのデプロイヤによって指定されたアプリケーション・リソースによって変更でき、ユーザーが変更できます。

導入されたバージョン:
1.3