社内で開発された一連の API を使用して、組織内の共通の中央サービスと通信しています。API は、システムの必要に応じて複数のトランスポート プロトコルを使用するようにランタイム構成によって動的に構成できます。
内部 API のコレクションは、必要なすべての Web サービスを構成して呼び出すために、IBM WebService thinclient.jar に結合されています。スタンドアロンのプロトタイプはスムーズに動作しましたが、機能を Grails で開発されている他のいくつかのサービスに統合する必要があります。
これは物事がバラバラになった場所です。私が書いたコードでは、ファクトリ メソッドを呼び出し、それを使用してクライアント セッションを取得し、ビジネス ロジックを続行します。単純。デバッガーを使用して API 呼び出しを掘り下げるgetClient()と、これが汎用トランスポート構成を取得し、それを SOAP トランスポート構成にバインドしていることがわかります。ここからは、純粋なスタンドアロンの Java サービスか、Grails アプリで実行されているサービスかによってパスが異なります。
純粋な Java スタンドアロンでは、これは メソッドが呼び出される
com.ibm.ws.webservice.engine.client.Service場所に バインドされ、期待どおりに動作します。initService()Grails アプリでは、同じ Java コードが含まれており、コード内の同じ場所で を呼び出してから
com.springsource.loaded.ri.ReflectiveIntercepter、スプリング ロード API を何度も行ったり来たりした後、最終的に java.lang.reflect.InvocationTargetException をスローします。
Grails でリフレクションをストレート Java と同じように動作させる方法について、ヒントやアイデアはありますか?
この点に到達するために多くのバリエーションを試しましたが、ロープの終わりに近づいています. 理想的には、ビジネス ロジックを管理する Grails サービスと、これらの内部システムと通信する Java コードを一緒に管理するのが最も簡単なので、すべて (Grails と Java サービス コード) を一緒に動作させたいと考えています。サービス コードとそのすべての依存関係のスタンドアロン JAR を簡単にビルドしようとしましたが、それを Grails で使用しようとすると、連鎖した依存関係の競合が発生しました。私の最後のオプションは、Java サービスを Grails サービスのビジネス ロジックとは別に立ち上げ、Grails サービスから Java サービスへの呼び出しを行うことです。これは理想的とは言えません。