Author |
Message
|
goffinf |
Posted: Mon Jan 28, 2013 12:18 pm Post subject: XMLNSC aware Java method |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
Version: 6.1.0.10
I have a Java method that I am calling from ESQL. I pass in one param as a REFERENCE on the ESQL side and MbElement on the Java method.
I call from ESQL and pass OutputRoot.XMLNSC as the Reference param :-
CALL doStuff(OutputRoot.XMLNSC);
public static void doStuff(MbElement messageTreeRoot)
Inside the Java method I start walking the tree passed in as the param.
Everything works (ish), but .... It appears that the tree that I am walking thru is NOT XMLNSC aware.
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. I wanted to exclude attributes from the processing that I am doing but as things stand I can't.
If I ask for the parser name associated with any node, XMLNSC is returned.
What do I need to do to maintain parser/domain awareness inside my Java method ?
Thanks
Fraser. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Jan 28, 2013 12:22 pm Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
goffinf |
Posted: Mon Jan 28, 2013 1:02 pm Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
Hmmm maybe, but I am walking the whole tree and need to make decisions based on the type of node (element / attribute / namespace decl / etc.).
The processing is generic, that is, it needs to work with any XML document, so I have no idea as to the names of the any of the nodes or their type before hand, .. It's just a standard recursive tree walk, I just need it to be XML aware.
I did try using getFirstElementByPath(*) to pull the first element node but that didn't work (hmmm maybe I'll try ./*)
Fraser. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Jan 28, 2013 1:10 pm Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
You could also try sending the payload downstream through a validation node (I don't remember if RCD node is available at your version) and then into a JCN rather than your current method of calling Java code without going through the JCN Mb interface.
If you enter the JCN through the message flow, you should be able to walk the tree with getNextSibling, etc. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
rekarm01 |
Posted: Mon Jan 28, 2013 2:38 pm Post subject: Re: XMLNSC aware Java method |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
goffinf wrote: |
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. |
What methods does the code use to determine field type? The MbElement class offers two methods: getType() returns the generic type (Name, Value, NameValue, etc.), and getSpecificType() returns the parser-specific field type. |
|
Back to top |
|
 |
kimbert |
Posted: Mon Jan 28, 2013 2:43 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
I know you are on v6.1, but I recommend that you take a look at the new JAXB tree access feature in WMB v8. It makes this sort of thing a lot easier.
Quote: |
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. I wanted to exclude attributes from the processing that I am doing but as things stand I can't. |
You can certainly test for the parser-specific flags via the Java API ( see rekarm01's reply above). |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Jan 28, 2013 2:58 pm Post subject: Re: XMLNSC aware Java method |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
rekarm01 wrote: |
goffinf wrote: |
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. |
What methods does the code use to determine field type? The MbElement class offers two methods: getType() returns the generic type (Name, Value, NameValue, etc.), and getSpecificType() returns the parser-specific field type. |
I believe his problem is he is calling into a Java subroutine without the benefit of the Java Compute Node (and thus the initialization of the MbElement tree). _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Jan 28, 2013 3:09 pm Post subject: Re: XMLNSC aware Java method |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
lancelotlinc wrote: |
rekarm01 wrote: |
goffinf wrote: |
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. |
What methods does the code use to determine field type? The MbElement class offers two methods: getType() returns the generic type (Name, Value, NameValue, etc.), and getSpecificType() returns the parser-specific field type. |
I believe his problem is he is calling into a Java subroutine without the benefit of the Java Compute Node (and thus the initialization of the MbElement tree). |
I suppose you're referring to the part where he is passing in OutputRoot rather than InputRoot.
It's possible, but not shown, that this has or has not already been initialized to a valid XMLNSC tree.
It's possible, but not shown either way, that this has been initialized to contain a valid OutputRoot tree that points to a valid XMLNSC parser structure that has been populated from another tree that did so without creating parser specific outputs (i.e. Set OutputRoot.XMLNSC = Environmnet.MyRandomTree). |
|
Back to top |
|
 |
goffinf |
Posted: Mon Jan 28, 2013 3:54 pm Post subject: Re: XMLNSC aware Java method |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
mqjeff wrote: |
lancelotlinc wrote: |
rekarm01 wrote: |
goffinf wrote: |
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. |
What methods does the code use to determine field type? The MbElement class offers two methods: getType() returns the generic type (Name, Value, NameValue, etc.), and getSpecificType() returns the parser-specific field type. |
I believe his problem is he is calling into a Java subroutine without the benefit of the Java Compute Node (and thus the initialization of the MbElement tree). |
I suppose you're referring to the part where he is passing in OutputRoot rather than InputRoot.
It's possible, but not shown, that this has or has not already been initialized to a valid XMLNSC tree.
It's possible, but not shown either way, that this has been initialized to contain a valid OutputRoot tree that points to a valid XMLNSC parser structure that has been populated from another tree that did so without creating parser specific outputs (i.e. Set OutputRoot.XMLNSC = Environmnet.MyRandomTree). |
Agreed I did not show that code from which the OutputRoot.XMLNSC reference that I pass into the Java method, but I can assure you it is a valid XML+namespace message.
I don't at this stage want to resort to a JCN unless the current route proves to be impossible or impractical.
rekarm01's suggestion looks most promising. |
|
Back to top |
|
 |
goffinf |
Posted: Mon Jan 28, 2013 3:55 pm Post subject: Re: XMLNSC aware Java method |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
rekarm01 wrote: |
goffinf wrote: |
For example, if I call 'getChild()' and that element has XML attribute children, they are found but their type is NOT MbXMLNSC.Attribute, they are simply PCDATA. |
What methods does the code use to determine field type? The MbElement class offers two methods: getType() returns the generic type (Name, Value, NameValue, etc.), and getSpecificType() returns the parser-specific field type. |
Ah, that's what that variant is for, sounds promising, thanks. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jan 28, 2013 5:02 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
And remember the reference shown by mqjeff. If you moved to the OutputRoot.XMLNSC from a tree that did not have a parser attached to it, all your attributes etc are kind of invalid as they are parser specific...
This might explain what you are seeing if the specific type does not resolve things...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
goffinf |
Posted: Tue Jan 29, 2013 5:04 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005 Posts: 401
|
fjb_saper wrote: |
And remember the reference shown by mqjeff. If you moved to the OutputRoot.XMLNSC from a tree that did not have a parser attached to it, all your attributes etc are kind of invalid as they are parser specific...
This might explain what you are seeing if the specific type does not resolve things...
Have fun  |
Yes indeed, although my code was already examining the parser associated with any node that it was processing and if it was XMLNSC looking for (I thought) MbXMLNSC types and if not the generic types available through MbElement.
Code: |
if(currentNode.getParserClassName().equalsIgnoreCase(MbXMLNSC.PARSER_NAME)){
...
|
The mistake I made was, in the case of XMLNSC to not use the getSpecificType() method pointed out by rekarm01.
Code: |
// int nodeType = currentNode.getType();
int nodeType = currentNode.getSpecificType();
if((nodeType == MbXMLNSC.PCDATA_FIELD) && (nodeType != MbXMLNSC.ATTRIBUTE)){
...
|
Now that I am, all is good in the world.
Thanks
Fraser. |
|
Back to top |
|
 |
mgk |
Posted: Tue Jan 29, 2013 9:08 am Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
Quote: |
I believe his problem is he is calling into a Java subroutine without the benefit of the Java Compute Node (and thus the initialization of the MbElement tree). |
It's worth pointing out for the benefit of future readers that a JCN does nothing special to initialize elements etc. Calling from ESQL is identical in this case.
Kind regards, _________________ MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
Back to top |
|
 |
|