私はマルチベンダーの JMS アダプターを作成していますが、いくつかのばかげたライセンスの問題により、狡猾なクラスローダー ソリューション/ハックの必要性が生じました。きれいにはなりませんが、専門家から独創的なアイデアを聞きたいと思っています。そこのクラスローダーハッカー...
アーキテクチャは単純です。アダプタはすべてのコードをシステム クラスローダに格納し、Sun の J2EE javax.jms.jar からのインターフェースを多用し、クラスパス情報に基づいて子 URLClassLoaders にこれらのインターフェースの個々の JMS プロバイダーの実装をロードします。一部の XML 構成ファイルからロードします。
これは、Sun の J2EE JMS jar が再配布を妨げる非常に煩わしいライセンスによって管理されていることに気付くまで (含まれているのは業界標準のインターフェイスだけであるにもかかわらず!)、システム クラスパスに単純に置くことができないことに気付くまで、すべて正常に機能していました。箱から出して私たちのコードと一緒に。しかし、顧客が Sun の Web サイトから jar を見つけてダウンロードし、それをインストールの適切な場所にコピーして機能させるように強制された場合、エンドユーザーのエクスペリエンスは非常に粗末なものになります。私たちがロードしている JMS プロバイダーの実装は、必ず私たち自身の JVM に既にロードされているすべてのインターフェースを持っていることを考えると、顧客にそのような苛立ちを強要するのは恥ずべきことです - 唯一の問題は、それらがプロバイダー固有の子クラスローダーにあることです。彼らの意味
ですから、これを解決するための巧妙なアイデアを聞きたいです (可能であれば!)。
たとえば、システムのクラスローダーを使用するのではなく、カスタマイズされた urlclassloader サブクラスにメイン クラスをロードしようとして (ただし、既存の MANIFEST.MF クラスパス参照の効果を再現する必要があることを考えると、それはかなりの苦痛になるでしょう)、そのクラスローダーを与えることについて疑問に思いました。子クラスローダーの 1 つへの参照 (XML 構成を解析した後) で、子から "javax.jms.*" インターフェイス (のみ) をロードできます (通常の親優先ポリシーを覆し、ベンダーを無視します)。 - 親にロードしてはならない同じ jar 内の特定のクラス)。これが実行可能である可能性が高いかどうか、および誰かが指針を持っているかどうか疑問に思っています。私' 欠落している JMS インターフェースを参照するメソッドがあるにもかかわらず、メイン CL の一部のアダプター クラスが正しくロードされることに気付きました (ただし、これらのメソッドが呼び出されると明らかに失敗します)。これらのクラスを含む CL にそのようなメソッドが呼び出されるまでに (ただし、クラスがロードされた後) JMS インターフェースにアクセスすると、それは機能しますか? （というかもう遅いのか…）
（参考までに、いくつかの有用なコンテキストを提供しますが、この指定された問題を完全には解決しない2つの関連するスタックオーバーフローの投稿をすでに見つけました：How do you change the CLASSPATH within Java? and How do I create a parent-last / child-first ClassLoader in Java ? 、または親 CL に既にロードされている古い Xerces バージョンをオーバーライドする方法は? )
これを手伝ってくれてどうもありがとう！:)