1

ファイル ベースの JNDI コンテキスト ファクトリを使用するcom.sun.jndi.fscontext.RefFSContextFactoryと、指定した場所に 1 つのバインディング ファイルしか許可されないようです。例えば

Hashtable properties = new Hashtable(2);
properties.put(Context.PROVIDER_URL,"file:///tmp/jms/mycontext");
properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory");
InitialContext ctx = new InitialContext(properties);

各ディレクトリにバインディングファイルがあるように、たとえば comp.env のディレクトリ構造を作成する方法はありますか? (バインディング ファイル自体で完全なコンテキストを指定する代わりに)

4

1 に答える 1

1

各ディレクトリは、パスとしてアクセスされるサブコンテキストです。ディレクトリは、それぞれがリーフ ノードとして .bindings を含むブランチ ノードです。各ブランチには、厳密に 1 つのリーフと、0 個以上の追加のブランチを含めることができます。

これを行う方法は、使用しているツールによって異なります。WebSphere MQ の JMSAdmin ツールから例を提供することはできますが、他のツールの構文はわずかに (または大幅に) 異なります。両方の例で Sun の FSContext が使用されているため、管理ツールの構文は異なる場合がありますが、コンテキスト トラバーサルは同じように機能します。

JMSAdmin を使用するDEFINE CTX(subcontext_name)と、.bindings ファイルが存在するディレクトリが作成されます。その後、そのサブコンテキストを現在のサブコンテキストにすることができますCHANGE CTX(subcontext_name)。定義したものはすべて、そのサブコンテキスト内の .bindings ファイルになります。

コードでは、サブコンテキストをパスとして参照します。たとえば、初期コンテキストを開いた後、オブジェクトを としてルックアップできますsubcontext_name/foo。

これの IBM 実装については、WebSphere MQ Using JavaマニュアルのManipulating Subcontextsにあります。構文は使用しているものと異なる場合がありますが、ツールは JMS に準拠しておりcom.sun.jndi.fscontext.RefFSContextFactory、原則は同じです。

于 2010-09-10T21:04:16.210 に答える