3

エンタープライズ アプリケーション A と B を (WLS 10.0 で) デプロイしています。A は「フレームワーク」、B はクライアント アプリです。クライアントは次の呼び出しを発行します。

Object o = ctx.lookup(jndiName); // line 1
cf = (ConnectionFactory) o; // line 2

ConnectionFactory はインターフェースであり、次のように定義されています。

public interface ConnectionFactory 
    extends java.io.Serializable, javax.resource.Referenceable {
    ...
}

何が起こるか：

  1. インターフェイス クラスを含む jar がシステム クラスパスにある場合、2 行目は正常に実行されます。
  2. インターフェイス クラスがシステム クラスパス上になく、アプリケーションとは別にパッケージ化されている場合、2 行目で ClassCastException がスローされます (これには、o が ConnectionFactoryImpl であるという情報テキストが含まれます)。

なぜこれが可能なのですか？JNDI ルックアップはリモート オブジェクトにスタブのみを返すと仮定します (この点で正しいでしょうか?) では、インターフェイス クラスのクラスローダーが異なる場合、なぜ問題になるのでしょうか?

私が期待する答えの種類：

  1. はい、それはあなたが経験したように起こるはずです...
  2. いいえ、それはこのように起こるべきではありません。
  3. あなたが説明した状況は非常に奇妙です。どこかの点を見逃していませんか?
  4. ... :)

また、誰かが JNDI とスタブがどのように機能するか、キャストがどこで行われるか (スタブのクライアント側で? またはリモート側の元のオブジェクトで?) などを明確にできるとよいでしょう。

ご協力いただきありがとうございます！

4

1 に答える 1

2

残念ながら答えは(1)です。

JNDI は、オブジェクトがツリーに格納される方法や、オブジェクトがクライアントに配信される方法についてのメカニズムを指示しません。操作を実行するために使用する単なる API です。

ここにあるように、両方のアプリケーションが同じ JVM にある場合、Weblogic はオブジェクトをクライアント アプリケーションに直接渡すだけである可能性が非常に高くなります。スタブはなく、「リモート側」です。そのオブジェクトによって実装された型はクライアント アプリケーションからは見えないため (型 ID はクラス名と、それがロードされたクラスローダーによって定義されることに注意してください)。

これは奇妙なことだと思うかもしれませんが、JavaEE 開発では、アプリケーションがこのように相互に対話することは標準ではないことに注意してください。アプリケーションは互いに分離され、システム レベルのリソースのみを共有することになっています。

于 2010-01-28T08:50:33.363 に答える