デバッグ時に、別の (独自の) クラスからメソッドを呼び出す行にブレークポイントを設定しました。スタックトレースのタイトルでエディタstep intoを取得します。
ブレークポイントのあるクラスに戻っている限り、それらをステップ オーバーできます。 Source not foundMyClass$Proxy$_$$_WeldClientProxy.myMethod() line: not available
Eclipse Kepler SR 1、Eclipse Juno SR 2、JBoss AS 7.1.1 および 7.2 を使用しても同じ問題が発生します。
これは、自動生成されたコードでよくある問題です。あなたは自分のオブジェクト (A としましょう) が別のオブジェクト (B としましょう) のメソッドを呼び出すと信じていますが、フレームワークは実際にはオブジェクト B をクラスが自動生成されるプロキシ B' に置き換えています。
プロキシ B' は元のオブジェクト B と同じインターフェイスを持ち、最終的に呼び出しを B に転送します。
自動生成されたコードはデバッガーを混乱させますが、ソース コードを表示せずにやみくもに [ステップ イン] をクリックすると、最終的には独自のコードに再び到達するはずです。都合が悪いのは言うまでもありません。
代わりにできることは、
関心のあるメソッドで停止する必要があります。呼び出されたプロキシの自動生成メソッドをスタックで確認できるはずです。
注: フレームワークをまったく使用しない場合でも、同様の問題が発生する可能性があります。実際、Java コンパイラ (javac)は、特に匿名クラスやブリッジ メソッドに対して合成コードを生成することがあります。
古い質問ですが、可能な解決策としてステップフィルターについて言及したいと思います。この問題を「解決」するには、ステップ フィルタを定義して、Weld プロキシをステップ オーバーし、実際に停止させたい場所で停止させることができます。
ワークスペースの設定を開き、「Java -> Debug -> Step Filtering」に移動して、「Add Filter」を選択します。フィルタリングするパターンとして「$Proxy*」を定義します。
Weld はクラスのプロキシを作成しました (説明については、こちらを参照してください)。この作成されたプロキシは、MyClass$Proxy$_$$_WeldClientProxyデバッグ中に表示されます。このプロキシは、最終的MyClass.myMethod()にコードである を呼び出します。そこに別のブレークポイントを置いて「実行」を押すか、そのメソッドに移動してEclipseで「行まで実行」します。
がインターフェイスである場合MyClassは問題であり、どの実装が実際に呼び出されるかわからない場合。すべての実装にブレークポイントを追加してください。インターフェイスのメソッドを選択して Ctrl-T (Eclipse のデフォルト ショートカット) を押すと、このメソッドのすべての実装を見つけるのに役立ちます。