問題タブ [cglib]

アスペクトで注釈が付けられた私のSpringコントローラーでは、CGLibプロキシを削除し、それらをJDK動的プロキシに置き換えようとしています。JDK動的プロキシはインターフェースでのみ機能するため、クラスがインターフェースを実装しない場合、Spring AOPはCGLibを使用することを知っています。また、インターフェースと実装クラスの両方に注釈が存在する必要があることも認識しています。しかし、私が直面している問題は、コントローラーが JDK プロキシーを持つ Bean として表示されなくなったことです。

私のコントローラ Bean は次のようにスキャンされます。

これは機能しますが、コントローラーは CGLibController$$EnhancerByCGLIB$$5f0b2287 として表示されます。

これは機能しません。Bean ポスト プロセッサに到達することはありません。

ただし、この DynamicController Bean を次のように明示的に作成すると、

次に、サーバーを起動すると、ServletContext が不平を言います

Bean の初期化に失敗しました。ネストされた例外は java.lang.IllegalStateException です: ハンドラー 'dynamicController' を URL パス [some_url] にマップできません: タイプ [クラス $Proxy61] のハンドラーが既にマップされています。

ここで何かが起こっています。DynamicController は動的プロキシです。しかし、他に何が起こっているのかはわかりません。もはや Bean/Controller ではないことはわかっています。「コントローラー、アスペクト、動的プロキシー: 任意の 2 つを選択」は必要ありません。3 つすべてが必要です。これはどういうわけか可能ですか？

以下に示す unittest クラスでは、テストの 1 つが失敗し、もう 1 つが成功します。どちらのテストもCGLIB、インターセプター モックを使用してオブジェクトを作成し、インターセプターが相互作用することを確認しようとします。テストは、CGLIB で動的にサブクラス化されるクラスによって異なります。成功するテストは、プレーンな Java インターフェースをサブクラス化します。失敗したものは、動的サブクラス (で作成Mockito) をサブクラス化します。最初のテストが失敗するのはなぜですか?

ありがとう。

アップデート：

障害のスタック トレース

また、Mockito モックが CGLIB 拡張クラスであるかどうかについては、以下のテスト (失敗) はそうではないことを示唆しているようです。

そのため、CGLIB 3 は数か月前からリリースされており、Spring 3.2も同様に機能しているように見えますが、Maven Central にない理由は不明です。

この依存関係が存在する別の Maven リポジトリはありますか?

Java ベースの構成で Spring 3.2 を使用していますが、単体テスト (JUnit 4.8.1) に問題があります。これはテストランナーです：

ただし、次のエラーが表示されます。

Spring ブログが述べているように、Spring 3.2 は CGLIB 3 をインライン化しています。では、なぜこのエラーが発生するのでしょうか?

Gradle 1.3 をビルド管理ツールとして、STS を IDE として使用しています。gradle eclipsegradle を呼び出すと、依存関係が 2 回取り込まれます。1 回はプレーン jar として、もう 1 回はライブラリとして:

最初にプレーンjarとして：

ライブラリとしてよりも：

単純な jar セクションにはまだ Spring 3.1 が構成されていましたが、ライブラリ セクションには Spring 3.2 がありました。だから私は普通の瓶を取り除き、すべてがうまくいった.

これは私のプロジェクトbuild.gradleです

そして、マスター プロジェクトの build.gradle

私はSpring 3.1.0でRest Serviceを持つプロジェクトに取り組んでいます。リリース。Config クラスを使用して Bean をロードしています。提案どおり、cglib 2.2 および asm-3.3 jar を使用します。

これは websphere 8.5 では失敗し、次の例外があります。ただし、Apache Tomcat 7.0 では動作します。

この問題を修正する方法に関する提案。

cglib と asm jar の異なるバージョンで試してみましたが、うまくいきませんでした..

spring-aop と cglib ライブラリを使用して、Spring 3.1 Web アプリケーションを作成しました。spring.xml:

つまり、すべての Bean に対して cglib を使用してプロキシが作成されます。

次に、com.mchange.v2.c3p0.ComboPooledDataSource で db 接続プール Bean を使用する必要があります。

問題は、ComboPooledDataSource クラスが final としてマークされていることです。また、cglib は最終クラスをプロキシできません。

「connectionPool」Beanをプロキシしないようにマークする方法は?

Java プロキシと cglib をチェックインしましたが、このプロジェクトを開始する方法についての例は見つかりませんでした。

これが私がしなければならないことです。

私はインターフェースを持っています：

と呼ばれるクラスの内部クラスとして、さまざまなタイプの都市がたくさんありますCities

次のように、クラスのさまざまな内部クラスをループすることにより、実行時にインターフェイスを実装できるようにしたいと考えていますCities。

型パラメーターが clazz 型のパラメーターである必要があることを除いて、すべての実装は同一です (for ループ内)。

これは可能ですか？もしそうなら、どこから始めるべきですか？Java Proxy と cglib はメソッドのインターセプトについてよく話しますが、それは私がここでやりたいことではありません。

ありがとう

ドキュメントに記載されているように、Cglib MethodInterceptor についていくつか混乱があります。生成されたすべてのプロキシされたメソッドは、元のメソッドの代わりにこのメソッドを呼び出します。元のメソッドは、Method オブジェクトを使用して通常のリフレクションによって呼び出すか、MethodProxy (より高速) を使用して呼び出すことができます。

しかし、以下のコードには java.lang.reflect.InvocationTargetException;why? によるエラーの原因があります。アドバイスをいただければ幸いです。

}

私はアイデアを使い果たしました、グーグルも助けませんでした。ユースケースは些細なことのようですが、ClassCastExceptionで失敗します。何が間違っているのかわかりません。特定のカテゴリに一致する最初の要素を返す簡単な方法があります。見てみましょう。

実行すると、このスタックの最上位になります。

エンティティを保持しているhibernateの永続コレクションを操作するためにlambdaJを使用しているときに、同じ問題が発生しました。すでにプロキシであるオブジェクト（コレクション内のエンティティ）のプロキシに問題がある可能性があると想定して、あきらめました。カテゴリとすべての継承されたクラスは、結果トランスフォーマーとして休止状態に渡されるpojoであるため、私は間違っていたようです。

そのような行動の理由は何でしょうか？何か考えはありますか？

（私は最新のlambdaj-2.4を使用しています）。

マリオのリクエストを満たすために追加されました

コードは単純な列挙型です。カテゴリはさまざまなカテゴリの基本クラスであり、コードフィールドがあります。さらに、これはパブリック静的クラスであり、すべての継承クラスと同じです（重要な場合）。

失敗したテストを提供しようとします。

追加情報を提供するために再度編集します。 私の友人がコードを調べて、この問題に新鮮な明るい光を当てました。

私は最初から私たちの控除の道を再現しようとします。

//与えられた

アプリケーションは2つの部分に分かれています。1つはベースアプリケーション（モデルファイルを保持）とWebアプリケーション（バッキングBeanなどのUI接続ファイルを保持）です。 カテゴリとコードはモデルクラスであるため、ベースアプリケーションに配置されます。次に、いくつかのWebロジックの目的でサービスを提供するバッキングBeanがあり、特にそのBeanまたはそのコラボレーターがselectを呼び出します。

// いつ

アプリケーションをWebサーバーにデプロイしています！私の場合はJBossです。クラスはローダーによって読み取られますが、私が気付いていない非常に複雑なことが起こり、すべてアプリケーションを実行します。私はいくつかのWebアクションを実行し、そのバッキングBeanのメソッドが呼び出されます

アプリケーションのWeb部分から。

これが魔法です。Category.classとCode.classは、アプリケーションのロード時にUnifiedClassLoaderによってロードされました。on（Category.class）メソッドを使用しており、Categoryのプロキシが構築されます。いくつかの本当に絡み合ったロジックがそれを行うために利用されています。最も重要なのは、プロキシが装備されていることです。

メソッドですが、Callback.classはそのクラスローダーから取得されます

したがって、最初にそのクラスであるUnifiedClassLoaderをロードしたのはクラスローダーです。これがすべてきれいに行われたので、私たちはついに電話します

リフレクションを使用すると、次を探しているプロキシクラスが参照されます。Proxy.getDeclaredMethod（ "setThreadsCallbacks"、new Class [] {Callback []。class}）;

私は事実を省略します、私は理解していません

この場合に重要なのは、Callback.classがUnifiedClassLoaderによって提供されないことです。アプリケーションはWebタイヤで実行されるため、Callback.classの呼び出しはWebアプリごとに行われます。クラスローダーとreturedCallback.classは、前述のsetThreadsCallbacks関数の引数として以前に配置されたものとは異なります。反射は残酷に失敗します。

そのため、失敗したテストを提供できませんでした。（同じクラスローダー）。

その場合の解決策はないと思います。