| Author |
Message
|
| McueMart |
 Posted: Tue Jul 24, 2012 12:54 am Post subject: Question about the Java debugger... |
 |
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I was wondering if any of the Hursley chaps could give some technical details about why the java debugger behaves the way it does....
When debugging ESQL code you are able to access the full message tree - something which is intuitive and makes debugging a huge amount easier.
When debugging Java, you are able to see the message objects (MbMessageAssembly etc...) , but they appear as stub objects which arent actually a full object model of the message. You cannot traverse the message in the debugger and see details about the fields etc.
Is it too performance degrading to create the complete logical object tree? Or is there other reasons why it is done this way?
If you are free to give this information out i'd be interested to hear it! |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Jul 24, 2012 4:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
If the object you are interested in is not parsed yet, then its not in memory, and not available to the debugger. (opaque)
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jul 24, 2012 5:28 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Example:
I have HTTPInput -----(Breakpoint)----> JavaCompute
On the breakpoint after the HTTPInput , I can see the complete logical message tree (regardless of whether I have On demand or Immediate parsing).
As soon as I step within the JavaCompute node, I can no longer 'navigate' through the logical model using the java objects (MbMessageAssembly/MbMessage etc). I had assumed it would be the same as in ESQL whereby when debugging, you can always access the complete logical tree (I think....). |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 24, 2012 5:30 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
In the JCN, I have to explicitly navigate to the element I am interested in using MbElement (Java code) to see it in the debugger. There may be another way, but thats how I do it.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jul 24, 2012 5:32 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Yes - thats my point. To actually see the value of an element your code must have navigated to it. This is not the same as the ESQL debugging experience (and it no way near as useful). I was interested in the technical reason for this. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 24, 2012 5:37 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
If you're designing, using the debugger to help you design is a poor way to do any design work.
If you want to see the tree as it exists, use a Trace node or take a user trace. Especially for real time requests (HttpInput or SOAPInput), the interactive debugger is not the choice, even if it did work the way your asking it to.
You should have Trace nodes before and after every major node in your flow.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jul 24, 2012 5:40 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I understand and use Trace nodes where appropriate. When writing ESQL I find the debugger extremely easy, fast and efficient to use. To say its not a good tool to use while developing would be naive statement. The Java debugger also has its uses - one I like is where it allows hot-swapping of code (so you can quickly test stuff without redeploying).
Each tool has its place....
Anyway - back on topic - I'd still like to hear the technical reason for the Java debugger functioning as it does  |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jul 24, 2012 5:45 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I'd still like to hear the technical reason for the Java debugger functioning as it does |
The message tree is a C++ data structure. The MbElement class can access individual syntax elements via a JNI wrapper but the references between the syntax elements ( parent, previousSibling, nextSibling, firstChild, lastChild ) reside outside of the JVM. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 5:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| Quote: |
| I'd still like to hear the technical reason for the Java debugger functioning as it does |
The message tree is a C++ data structure. The MbElement class can access individual syntax elements via a JNI wrapper but the references between the syntax elements ( parent, previousSibling, nextSibling, firstChild, lastChild ) reside outside of the JVM. |
This only tangentially relates to the behavior that the Toolkit portions of the debugger choose to display. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jul 24, 2012 5:48 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Ah ha! Thanks for clearing that up! |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jul 24, 2012 5:58 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
mqjeff: I think McueMart was wondering why he cannot navigate around the message tree from within the 'variables' view of the Java debugger.
I may be wrong in assuming that, of course. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 24, 2012 5:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
mqjeff: I think McueMart was wondering why he cannot navigate around the message tree from within the 'variables' view of the Java debugger.
I may be wrong in assuming that, of course. |
I agree!
I'm saying that Toolkit could have chosen to implement this, despite the technical challenges you've mentioned. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jul 24, 2012 6:03 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Probably true - sounds like a good idea for somebody to implement as a fix pack. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jul 24, 2012 6:20 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Yes you are exactly right about wanting to navigate around the variables view. Fixpack sounds a very good idea |
|
| Back to top |
|
|
| inMo |
| Posted: Tue Jul 24, 2012 8:56 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
|
| Back to top |
|
|
|
|
