JNDIファクトリBeanを接続するときにエラーを見つけようとして、1日の時間を費やしすぎました。問題はこれの代わりにそれであることが判明しました...
<bean id="someId" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="Java:comp/env/jdbc/loc"/>
</bean>
私は実際にこれを書いていました...
<bean id="someId" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="jdbc/loc"/>
</bean>
Java:comp/env /はおそらくいくつかの環境変数を参照し、最終的にはコンテキストファイルが参照されるように作成すると推測します。唯一の違いはJava:comp/env /です。専門家の口から、それは何をしますか?
値にJava:comp/envプレフィックスがないと、「名前jdbcはこのコンテキストにバインドされていません」というエラーが表示されます。
名前空間のルートコンテキストには、「comp」という名前のバインディングがあります。これは、コンポーネント関連のバインディング用に予約されたサブツリーにバインドされています。 「comp」という名前は、コンポーネントの略です。ルートコンテキストには他のバインディングはありません。ただし、ルートコンテキストは、ポリシーの将来の拡張、特にコンポーネント自体ではなく、ユーザーや部門などの他のタイプのエンティティに関連付けられているリソースの命名のために予約されています。たとえば、将来のポリシーでは、「Java:user/alice」や「Java:org/engineering」などの名前を使用して、ユーザーや組織/部門に名前を付けることができます。
「comp」コンテキストには、「env」と「UserTransaction」の2つのバインディングがあります。 「env」という名前は、デプロイメント記述子で定義されている、コンポーネントの環境関連のバインディング用に予約されているサブツリーにバインドされています。 「env」は環境の略です。 J2EEは、「env」名前空間に次の構造を推奨しています(必須ではありません)。
したがって、Springから、または例えばTomcatコンテキスト記述子から行ったバインディングは、デフォルトでJava:comp/env /の下に行きます。
たとえば、構成が次の場合:
<bean id="someId" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="foo"/>
</bean>
次に、次を使用して直接アクセスできます。
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("Java:comp/env/foo");
または、取得するすべてのリソースに「Java:comp/env」を指定する必要がないように中間ステップを作成できます。
Context ctx = new InitialContext();
Context envCtx = (Context)ctx.lookup("Java:comp/env");
DataSource ds = (DataSource)envCtx.lookup("foo");
resourceRef
のプロパティJndiObjectFactoryBean
もあります。つまり、true
に設定されている場合、文字列Java:comp/env/
がまだ存在しない場合に自動的に付加するために使用されます。
<bean id="someId" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="jdbc/loc"/>
<property name="resourceRef" value="true"/>
</bean>
数回試行し、Tomcatのソースコードを詳しく調べたところ、単純なプロパティ seNaming = "false" がトリックを行っていることがわかりました!! Tomcatは名前を解決するようになりましたJava:/ liferayではなくJava:comp/env/liferay