Debugging's step into won't work on own code: MyClass$Proxy$_$$_WeldClientProxy.myMethod() line: not available

Question

When debugging I set a breakpoint to a line that calls a method from another (own) class. On step into I get a Source not found in the editor with the title MyClass$Proxy$_$$_WeldClientProxy.myMethod() line: not available in the stacktrace.
I can step over those as long as I am back in the class with the breakpoint.

I have the same problem using Eclipse Kepler SR 1, Eclipse Juno SR 2 and JBoss AS 7.1.1 and 7.2.

Thrombocyte

Answer 1

That's a common problem with autogenerated code. You believe that an object of yours (let's call it A) invokes a method on another object of yours (let's call it B), but the framework has actually replaced your object B with a proxy B' whose class is autogenerated.

The proxy B' has the same interface as your original object B, and eventually forwards the invocation to B.

Autogenerated code will confuse the debugger, but if you click "step into" blindly -- without seeing the source code -- you should eventually reach your own code again. Needless to say that it's not convenient.

What you can do instead is to

1. set a breakpoint in the class of B you are interested in
2. use "run" instead of "step into"

That should stop into the method you are interested in. You should be able to see in the stack the autogenerate methods of the proxy that have been invoked.

Note: you might have similar problem even if you don't use any framework at all. Indeed, the java compiler (javac) already generates synthetic code sometimes, notably for anonymous classes, and bridge methods.

Heaver

Thank you for your helpful answer. I could swear there were times when I could step easily into my own classes from another class - with the same architecture. So there is no way to just step conveniently through the code and see what actually happens at each step? – Thrombocyte

@Leister did you change something in the configuration of Weld (e.g. via some annotation)? Instead of injecting the original object, the framework injects a proxy. It doensn't necessary mean you changed your design. – Heaver

I might have changed some scopes like @SessionScoped to @RequestScoped etc. What annotations could be responsible? I never really cared what CDI-Implementation I was using and how it worked as long as it worked. What kinds of framework could inject a proxy? – Thrombocyte

Answer 2

Weld has created a proxy for your class (you may want to look here for an explanation). This created proxy is the MyClass$Proxy$_$$_WeldClientProxy you see while debugging. This proxy will eventually call MyClass.myMethod(), which is your code. Put another breakpoint there and hit "Run", or go to that method and "Run to line" in Eclipse.

It would be a problem if MyClass is an interface, and you do not know which implementation will actually get called; well brute force to the rescue, add a breakpoint to every imnplementation! Having selected the method of the interface and pressing Ctrl-T (default shortcut of Eclipse) will help you find all implementations of this method.

Duplicature

Thank you for your helpful answer. I could swear there were times when I could step easily into my own classes from another class - with the same architecture. So there is no way to just step conveniently through the code and see what actually happens at each step? – Thrombocyte

Answer 3

Old question, but I really want to mention step filters as a possible solution. To "solve" the issue you can define a step filter which will make step-into to step over the Weld proxy and stop where you actually want it to stop.

Open your workspace preferences, navigate to "Java -> Debug -> Step Filtering" and select "Add Filter". Define "$Proxy*" as the pattern to filter.

Knapweed