I was asked in another post (http://forums.smartclient.com/forum/...812#post234812) to explain how I had stepped into the Isomorphic Java libraries while debugging an issue I was experiencing.
It's been so long since I setup my environment that I had, frankly, forgotten the detail of how I did, but I did a little poking around and if I have remembered to line up all my ducks properly, it turns out the preparation is easier than I remembered. This technique should work for more than just the Isomorphic libraries, and it's probably well (and better) documented elsewhere if you don't mind a quick trip to the Google, but since SmartGWT is the topic of this forum and it is with SmartGWT that I generally employ it, here goes...
First things first, and no surprise, you need to install a decompiler in your Eclipse IDE. I appear to have installed JD-Eclipse, which you can find, along with installation instructions, at https://github.com/java-decompiler/jd-eclipse.
Next, if you are running your app server as a separate process (I run Tomcat externally to Eclipse) you need to setup a debug configuration to attach the Eclipse debugger to that process:
Now, it's just a matter of decompiling the class you are interested in, which you do simply by opening the relevant package within the JAR file you will be working with, and then double-clicking the class you are interested in. For example, I often find I need to start with the com.isomorphic.datasource.DataSource.class contained in isomorphic_core_rpc.jar.
Once I open the class and can see the decompiled source, I can set a breakpoint as normal. If I'm not sure which method I should set my breakpoint, I might set one in an often-called method, such as execute() in this case.
How do I know which class I'm interested in? Often it's from an exception stack trace, in which case I should know the method name and line number also (I have set JD-Eclipse to show original line numbers in Window / Preferences / Java / Decompiler).
Or perhaps I'm just seeing a behavior that I can't explain in my code. I can probably trace up to the point that I know I'm going to end up in Isomorphic code. If I simply step into that code without first decompiling the class, I have found that I am presented with the familiar "No source code found..." message - at least that's my experience.. However, if I have decompiled that class beforehand, it steps neatly right into it.
Here you can see I set a breakpoint in our custom datasource class that extends com.isomorphic.sql.SQLDataSource. I have set the breakpoint on a line which I am quite certain will take me into the com.isomorphic.datasource.DataSource class:
Now when I step into the method I am taken right into the decompiled source:
Notice that the line number in the top of the stack trace shown in the bottom right of the screen (UIStateDS(DataSource).execute(DSRequest) line: 1901) corresponds to the line number in the decompiled source. In this case, then, my line numbers are lining up as I would hope and I don't have to resort to any undue jiggery-pokery. I have found that sometimes the line numbers get a bit mixed up. I don't know whether it's Eclipse, JD-Eclipse, the libraries, or just something in my environment. However, while in the Debug perspective the Debug tab shows the the exact line number on which the debugger is stopped. Since I have original line numbers showing I can usually find my way by cross-referencing the two. In most cases, though, the line numbers seem to be correct, but I point it out in case you can't understand why you suddenly stepped into the middle of a method...
As far as I can tell, all the functions of the debugger are available to you here, so you can peek and poke to your heart's desire as you would within your own code. I could go on (and people say that I do), but you probably know your way around the debugger better than me. Once you have a decompiler installed, the key is to decompile your class before you step into it. Maybe there's something I'm overlooking which makes that easier, but to be honest with you it hasn't been worth my effort to investigate than further.
With that said, if anyone would like to contribute any corrections or additions to what I have outlined here, please do so.
It's been so long since I setup my environment that I had, frankly, forgotten the detail of how I did, but I did a little poking around and if I have remembered to line up all my ducks properly, it turns out the preparation is easier than I remembered. This technique should work for more than just the Isomorphic libraries, and it's probably well (and better) documented elsewhere if you don't mind a quick trip to the Google, but since SmartGWT is the topic of this forum and it is with SmartGWT that I generally employ it, here goes...
First things first, and no surprise, you need to install a decompiler in your Eclipse IDE. I appear to have installed JD-Eclipse, which you can find, along with installation instructions, at https://github.com/java-decompiler/jd-eclipse.
Next, if you are running your app server as a separate process (I run Tomcat externally to Eclipse) you need to setup a debug configuration to attach the Eclipse debugger to that process:
Now, it's just a matter of decompiling the class you are interested in, which you do simply by opening the relevant package within the JAR file you will be working with, and then double-clicking the class you are interested in. For example, I often find I need to start with the com.isomorphic.datasource.DataSource.class contained in isomorphic_core_rpc.jar.
Once I open the class and can see the decompiled source, I can set a breakpoint as normal. If I'm not sure which method I should set my breakpoint, I might set one in an often-called method, such as execute() in this case.
How do I know which class I'm interested in? Often it's from an exception stack trace, in which case I should know the method name and line number also (I have set JD-Eclipse to show original line numbers in Window / Preferences / Java / Decompiler).
Or perhaps I'm just seeing a behavior that I can't explain in my code. I can probably trace up to the point that I know I'm going to end up in Isomorphic code. If I simply step into that code without first decompiling the class, I have found that I am presented with the familiar "No source code found..." message - at least that's my experience.. However, if I have decompiled that class beforehand, it steps neatly right into it.
Here you can see I set a breakpoint in our custom datasource class that extends com.isomorphic.sql.SQLDataSource. I have set the breakpoint on a line which I am quite certain will take me into the com.isomorphic.datasource.DataSource class:
Now when I step into the method I am taken right into the decompiled source:
Notice that the line number in the top of the stack trace shown in the bottom right of the screen (UIStateDS(DataSource).execute(DSRequest) line: 1901) corresponds to the line number in the decompiled source. In this case, then, my line numbers are lining up as I would hope and I don't have to resort to any undue jiggery-pokery. I have found that sometimes the line numbers get a bit mixed up. I don't know whether it's Eclipse, JD-Eclipse, the libraries, or just something in my environment. However, while in the Debug perspective the Debug tab shows the the exact line number on which the debugger is stopped. Since I have original line numbers showing I can usually find my way by cross-referencing the two. In most cases, though, the line numbers seem to be correct, but I point it out in case you can't understand why you suddenly stepped into the middle of a method...
As far as I can tell, all the functions of the debugger are available to you here, so you can peek and poke to your heart's desire as you would within your own code. I could go on (and people say that I do), but you probably know your way around the debugger better than me. Once you have a decompiler installed, the key is to decompile your class before you step into it. Maybe there's something I'm overlooking which makes that easier, but to be honest with you it hasn't been worth my effort to investigate than further.
With that said, if anyone would like to contribute any corrections or additions to what I have outlined here, please do so.
Comment