| Author |
Message
|
| lalli_urs |
 Posted: Mon Aug 12, 2013 5:45 am Post subject: java.lang.NullPointerException in java compute node |
 |
|
Novice
Joined: 10 Nov 2010
Posts: 10
|
Hello,
I have written a program to add two numbers using Java Compute Node but while executing it is throwing the Null pointer exception error.
The flow is MqInput node --> Java Compute Node --> MqOutput Node
The code in Java Compute Node.
| Code: |
MbMessage message = assembly.getMessage();
MbElement element1=message.getRootElement().getFirstElementByPath("XML/INPUT");
String object1=element1.getFirstChild().getValue().toString();
int no1=Integer.parseInt(element1.getFirstChild().getValue().toString());
int no2=Integer.parseInt(element1.getLastChild().getValue().toString());
int no3=no1+no2;
Integer result=new Integer(no3);
MbMessage message1=new MbMessage(message);
MbElement element2=message1.getRootElement().getFirstElementByPath("XML/INPUT");
element2.createElementAsLastChild(0x1000000,"TOTAL",result);
element2.setName("OUTPUT");
MbMessageAssembly assembly1= new MbMessageAssembly(assembly,message1);
out.propagate(assembly1);
|
Input Message:
<INPUT><NO1>34</NO1><NO2>76</NO2></INPUT>
Can someone help me on this ...   |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Aug 12, 2013 5:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
First off - use [c o d e] tags in your posts.
Second - you are not guaranteed to have a non-null value from getValue(). Therefore, you must code defensively and put try-catch blocks in your code.
Third - since you are new - you need to do your own homework. This is basic Java. Ask your coach or mentor on your site to help you.
Fourth - use Trace node after your input node to see exactly what the Logical Message Tree is. Then write your code accordingly.
Fifth - An ESQL Compute node is more appropriate rather than a JCN.
Sixth - Have you attended the WMB Developer training classes? https://www-304.ibm.com/jct03001c/services/learning/us/pdfs/roadmaps/wmb_v8_dev.pdf If not, why not?
Seventh - go back and 'EDIT' your post above to add the [c o d e ] tags.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 12, 2013 6:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Code: |
| MbElement element1=message.getRootElement().getFirstElementByPath("XML/INPUT"); |
This is inappropriate and does not do what you think it does.
Or if it does you are using a deprecated domain and should be using XMLNSC instead....
This is partly the reason you are getting the null pointer exceptions
BTW getFirstElementByPath is not suited if you have namespaces...
Have fun and get training. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| christian.witschel |
| Posted: Mon Aug 12, 2013 11:44 pm Post subject: we all start somewhere |
|
|
Newbie
Joined: 11 Aug 2013
Posts: 5
|
dude good choice trying with java  Just dont listen too much to all the ESQL is best folks. (yes, ESQL is 5% faster in the lab, i know... but so is ABAP  )
My advice: make sure on the MQInput you turned the XMLNSC Parsing on and set it to immediate for now (later for performance sake you can switch it back to on demand).
then use the following
| Code: |
| MbElement element1=message.getRootElement().getLastChild().getFirstChild(); |
The last child of the message is always the body/payload/parsed content. This way you circumvent the any naming issue. Looking at the xml sample you have given, there is only one child input so getFirstChild will return that one.
Now regarding the defensive java coding: when navigating around the logical message tree you need to use lots of logic and be sure how the data looks like. That is why it is a good idea to always define a message model (import the xsd of your xml) and turn on parsing + validation, so you can be sure the input data looks like you expected at coding time.
otherwise when fishing in unknown xml waters use the evaluatexpath methods.
Also there is a getValueAsString method. Use it instead of getValue().toString(), cause that might just return you the class name or some other surprising result.
regards |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Aug 13, 2013 12:57 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Just dont listen too much to all the ESQL is best folks. |
I agree. And don't listen to the 'Java is best' folks either. Listen to the 'use the best language for your skill set, and learn it well' folks. 
| Quote: |
| My advice: make sure on the MQInput you turned the XMLNSC Parsing on |
Yes - use XMLNSC.
| Quote: |
| The last child of the message is always the body/payload/parsed content. This way you circumvent the any naming issue. |
Yes. ESQL provides the correlation name 'InputBody' for exactly that reason.
| Quote: |
| Now regarding the defensive java coding: when navigating around the logical message tree you need to use lots of logic and be sure how the data looks like. That is why it is a good idea to always define a message model (import the xsd of your xml) and turn on parsing + validation, so you can be sure the input data looks like you expected at coding time. |
Alternatively ( if on v8 or later), generate JAXB classes from your xsds and use those. That would be my recommendation.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| lalli_urs |
| Posted: Tue Aug 13, 2013 2:20 am Post subject: |
|
|
Novice
Joined: 10 Nov 2010
Posts: 10
|
Thanks All for your suggestions and support.
I have changed the Input Message parsing property of MQInput Node to XMLNSC and also changed the code MbElement element1=message.getRootElement().getFirstElementByPath("XMLNSC/INPUT");
Finally it worked as expected.  |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Aug 13, 2013 12:15 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| kimbert wrote: |
| Listen to the 'use the best language for your skill set, and learn it well' folks. |
Who except IBMers says that? I am truly looking forward to the day, when you (IBM) let go from this. Thank you for putting (next to ESQL) in all the choices (recently, and with recently I mean a couple of years). It must have been a great effort and I can really see that you are proud of it. We all agree that it is a great selling point.
The idea that people know and use one particular language is old fashioned.
It turned out (in IT generally) that its better to use the best fitted language/tool for (your) problem.
ESQL was written with the target problem (systems integration, msg processing&transformation) in mind and it has unmatched facilities (the way to navigate within the message (e.g. "*.*[<]"), how to create the output message (e.g. "{}" ) and the underlying runtime (performant c runtime with a specific/custom mem-management)), which exactly address the needs in this area.
Java comes from a different background, then it was applied to our problem-domain (it also adds some questionable 'at that time hype technology', like xPath) and it gets more bumpy with it in our field.
Please IBM, use it as a selling point and reduce advice on it in a technical forum.
It makes a difference in which direction you are steering the boat!
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Aug 13, 2013 12:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| kimbert wrote: |
| Listen to the 'use the best language for your skill set, and learn it well' folks. |
Who except IBMers says that? |
Anyone who's seen what a poorly skilled JEE programmer will do when given Broker and told to be productive in three days.
"Why did you write an EJB to process the logical message tree?"
That's a technical point, not a selling point. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Aug 13, 2013 1:09 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Dear ((poorly) skilled) JEE programmer,
Neither tend to write EJBs with Broker and probably do not use Broker's JCN (which may prevent you form writing EJBs to process the logical msg tree ?!)... just start using ESQL (as soon as possible)! Maybe use it in a poor way in the beginning (maybe start with simple scenarios then/also)... and discover step by step (just use google (and (also) end up on mqseries.net )) what it can do for you (both during development as well as in the production environment). All you have to do (right) in ESQL you would have also to do in a JCN and... language (and language syntax) doesn't matter that much today. What matters more is what the language/environment provides for you and how it provides it to you. Try to be on the right track (from the beginning).
Yours sincerely,
mqsiuser (contributor and author of important stuff in this area)
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 14, 2013 4:11 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| mqsiuser wrote: |
| kimbert wrote: |
| Listen to the 'use the best language for your skill set, and learn it well' folks. |
Who except IBMers says that? |
Anyone who's seen what a poorly skilled JEE programmer will do when given Broker and told to be productive in three days.
"Why did you write an EJB to process the logical message tree?"
That's a technical point, not a selling point. |
Your average message flow developer (1) has no idea what the Logical Message Tree is or (2) how to use the part of LMT called Environment.Variables or (3) the fact that InputRoot is read-only.
For clarity, I advocate the use of all nodes, not just ESQL or Java. The reason I mentioned that ESQL is more appropriate here is because its more convenient to use ESQL constructs to interrogate the LMT rather than XPath for such a simple message example as was posted by the OP.
WMB nodes are not mutually exclusive. You can use any one you wish to do what best fits that node. Unless you have a manager who is less informed...
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Aug 14, 2013 4:42 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
Your average message flow developer (1) has no idea what the Logical Message Tree is or (2) how to use the part of LMT called Environment.Variables or (3) the fact that InputRoot is read-only.
|
I guess that this mythical person has not attended the training you so often recommend?
The training course I attended DID cover these topics but there again, V2.0.2/2.1 was a much simpler product so the 5 day course could spend time on these rather essential topics.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Aug 14, 2013 6:38 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| lancelotlinc wrote: |
(3) the fact that InputRoot is read-only.
|
Not true. InputRoot used to be read-only back in 2.1 but if I remember well, in V5 it was made read-write, to be able to handle large messages, so you can delete or change parts of it. I know the toolkit will give you an error if you try to alter it directly, but that is a different matter.
If you don't believe me, and before people start shouting at me, try the following:
| Code: |
DECLARE cursor REFERENCE TO InputRoot.XMLNSC.mymsg;
SET cursor.myfield = 'changed';
SET OutputRoot.XMLNSC.Test.field = cursor.myfield;
|
That will fool the toolkit, and you will see that InputRoot was changed. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 14, 2013 7:00 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| dogorsy wrote: |
| lancelotlinc wrote: |
(3) the fact that InputRoot is read-only.
|
Not true. InputRoot used to be read-only back in 2.1 but if I remember well, in V5 it was made read-write, to be able to handle large messages, so you can delete or change parts of it. I know the toolkit will give you an error if you try to alter it directly, but that is a different matter.
If you don't believe me, and before people start shouting at me, try the following:
| Code: |
DECLARE cursor REFERENCE TO InputRoot.XMLNSC.mymsg;
SET cursor.myfield = 'changed';
SET OutputRoot.XMLNSC.Test.field = cursor.myfield;
|
That will fool the toolkit, and you will see that InputRoot was changed. |
Maybe it is better said this way: unskilled message flow developers fail to treat InputRoot as read-only.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Aug 14, 2013 7:09 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Quote: |
Maybe it is better said this way: unskilled message flow developers fail to treat InputRoot as read-only.
|
And why would they ? if it can be modified and you need to modify it, then why not? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Aug 14, 2013 7:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| dogorsy wrote: |
| Quote: |
Maybe it is better said this way: unskilled message flow developers fail to treat InputRoot as read-only.
|
And why would they ? if it can be modified and you need to modify it, then why not? |
I go into this in depth in my Tips&Tricks book. Its a matter of good organization.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
