これがかなり長く詳細な投稿であることは承知しています。できれば、もっと短くシンプルにしたかったのに。アドバイスやアイデアをいただければ幸いです。
バックグラウンド
2 つのアプリケーション間でデータを転送する XSLT を作成しています。それらをソースとターゲットと呼びます。私の XSLT は、ソース システムのサプライヤが提供する統合エンジンによって呼び出されます。Source Co と呼んでください。
統合エンジンは、ターゲット システムのサプライヤによって記述された API をラップするエンジンに含まれるアダプタを呼び出すことによって、ターゲットを更新します。それらを Target Co と呼びます。これはすべて J2EE サーバー内で実行されます。
統合エンジンが Java EE サーバーにデプロイされると、ターゲット システム API を実装する JAR ファイルがエンジンのクラスパスに配置されるようにコピーされます。
私の状況
ターゲット CO の API をラップするソース Co のアダプタは、API のサブセットのみを公開します。顧客のビジネス要件を満たすには、Source Co Adapter を使用せずに Java から直接 API を呼び出すしかない場合があります。
私はすでにこれを達成しました：
- DOM ドキュメントを受け入れて返し、API を呼び出す Java クラスを作成する
- それらをJARとしてJava EEエンジンにデプロイし、統合エンジン、つまりXSLTに見えるクラスパスに配置する
- 私の XSLT では、名前空間を宣言して Java クラスを指定し、その名前空間を介して適切な public static メソッドを呼び出します。
これはすべてうまくいきます。でも...
私の問題
Target Co の API の最近のバージョンには次のものがあります。
- いくつかの廃止されたメソッドを削除しました
- ターゲット システム内の追加のビジネス エンティティへの公開アクセス
Source Co のアダプタはこれらの削除されたメソッドを使用するため、クラスパスに古いバージョンの Target Co API が必要です。
お客様の最新のビジネス要件は、最新の API を使用してこれらの追加のビジネス エンティティにアクセスすることによってのみ満たすことができます。
私の質問
統合エンジンのアダプターのクラスパス上になくても、拡張機能のクラスパス上に最新バージョンの API を配置するにはどうすればよいですか?
もちろん、カスタム クラス ローダーを使用することもできます。クラスパスにあった場合、統合エンジンも壊れていたサードパーティのデータベースドライバーjarをロードするためにこれを行いました。データベース ドライバの場合、カスタム クラスローダを 1 回使用するだけです。しかし、現在のケースでは、コード全体に散らばるクラスローダーへの非常に多くの呼び出しを回避する方法がわかりません。これは非常に間違っていると感じています。
いくつかの技術的な詳細
ソースシステム - SAP
ターゲット システム - Oracle の Primavera
Java EE エンジン - Netweaver 7.2
XSLT プロセッサ - サクソン