I was testing Bug 134276 and everything seemed to be working fine before I tried Step Into: if I place breakpoint in Servlet and then try to Step Into an EJB call (Local or No-Interface) the step into happens but it stops in completely unrelated place: java.util.Arrays.copyOf() or java.lang.reflect.Method.getDeclaringClass(). Any idea what's wrong? I tried to disable JDK sources and then Step Into stopped working completely. If I place breakpoint in implementation of EJB method then debugger stops there correctly.
I am trying with the latest dev build and it still does not work. Right now, whether or not JDK sources are available, if there is no breakpoint in the EJB, step into on the EJB call does not get into the EJB, but instead behaves like step over, i.e. progresses to the next line in the servlet. Martine, could you please investigate? Thanks.
The problem is reproducible for me as well. I have encountered both cases described above. Sometimes Step Into stops at "unrelated" places, sometimes it does not stop at all and behaves like Step Over.
The explanation seems to be as follows. EJB object in servlet is represented by a wrapper and method calls performed on it are not delegated directly to the method we try to Step Into. There is a long chain of reflections and other calls. Some of the reflections invoke native methods, this is probably the reason, why debugger does not reach the desired EJB source since it is not able to continue in stepping trough them - this is my guess, I need to investigate it in more details.
Do we know if Step Into EJB from a servlet has ever worked?
It is not clear, why the behavior is not deterministic. I obtained two different results, when I tried one fixed scenario several times:
- debugger stopped at org.omg.CORBA.portable.ObjectImpl._get_delegate()
- debugger performed Step Over
There might be something more involved in this bug.
Dane, thanks for the investigation. To your question:
> Do we know if Step Into EJB from a servlet has ever worked?
Possibly not - maybe this never worked.
The debugger is able to step trough native methods, however, it is required to have related option "Step trough the filters to reach unfiltered code" enabled in Java Debugger options. It is disabled by default.
After that, Step Into EJB regularly stops at the "unrelated" code, which is expected behavior, since the EJB object wrapper calls methods from org.omg.CORBA.*, java.util.* and java.lang.reflect.* before the called EJB method is reached.
We have found a solution that could improve debugger stepping logic and should fix the problem, however, the change is risky for nb 6.9 release (we are afraid of some unwanted side effects). We prefer to wave this issue and integrate the fix to trunk only.
Idea of the fix: Step into a method, check whether sources are available for the position the debugger is stopped at, if not, continue with stepping into and ignore jdk and library sources, stop at the nearest available source file from user's project.
Note that a workaround for a direct stepping into EJB code from servlets exists, it can be done using the following set up:
1) In Java Debugger options, go to Step Filters, enable "Step trough the filters to reach unfiltered code" and add stepping filter for "org.omg.CORBA.*" classes.
2) In Sources view, disable jdk sources.
Requesting a waiver for NB 6.9. The workaround is to set a breakpoint in the EJB implementation code and use Step Over.
This now seems to work correctly. Martin, can you please confirm that the fix described by Dan is indeed integrated? If it is, let's close as fixed. Thanks.
I've setup a reproducible test case.
In the default setup this still does not work, Step Into acts like Step Over, since "Step through the filters to reach unfiltered code" option is not enabled by default.
When turned on, the execution stops at various places in JDK sources. It's necessary to disable debugging of JDK sources in Window -> Debugging -> Sources.
It would be ideal to create a different default setup for debugging EJBs.
I do not like the solution described by Dan as it would affect ordinary JDK debugging.
Ok, thanks. It sounds like there is a workaround, so lowering priority to P3. Another workaround is to of course set a breakpoint in the EJB implementation.