| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CDATA section with xml and "]" in it and larger th |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqsiuser |
 Posted: Mon Apr 07, 2014 12:01 pm Post subject: CDATA section with xml and "]" in it and larger th |
 |
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
just to let you know,
we ran into something which looks like a XMLNSC parser bug to us:
Create a xml msg with a CDATA section that also includes xml and within it's "data" (element or attribute) at least one closing square bracket "]"
Then increase the size of the xml message (we increased the size of the xml in the cdata section): We found that things work fine up to 32kb on IIB9 on redhat and 8kb on Broker 7 on Windows and after that the cdata-section will be split (only by accessing it with the parser) at the "]" (actually at each) into "another" node/child in the msg tree.
There should only be one element though and not another one (only because a square bracket appeared) for the CDATA-section.
The strange behaviour (actually a bug for us) can be easily seen in the debugger. Or try to access the CDATA-Section in ESQL, then (I think) you will only get the first child or last (of the several created)... basically also an error. If you just/only pass everything (the full msg) through it will be written out fine. That's at least what we found out.
First tests with XMLNS parser did not show the error (probably we switch temporarily to XMLNS).
I guess we have already opened a PMR (this is not my job  ).
_________________
Just use REFERENCEs |
|
| Back to top |
|
 |
| kimbert |
| Posted: Tue Apr 08, 2014 3:51 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
This is a known issue. The XMLNSC parser works this way because it could be dangerous to create single strings of arbitrary size in the message tree.
A DOM tree ( or a message tree that represents an XML document ) is allowed to represent the text content of a node using one or more child nodes. So the XMLNSC parser is not behaving badly - other XML parsers do similar things. It could be better documented, though.
If your ESQL does not cope with this, then it might also fail to cope with other types of text content. Try adding a line break before/after the CDATA section and you will see what I mean. In this case, the parser has no choice about splitting the text content into multiple nodes - the CDATA section needs to be represented by a special type of node, so the white space either side of it must be represented separately. This is standard behaviour, not an XMLNSC quirk. Does your ESQL cope with this?
_________________
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 |
|
|
| mqsiuser |
| Posted: Tue Apr 08, 2014 4:44 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| kimbert wrote: |
| This is a known issue. The XMLNSC parser works this way because it could be dangerous to create single strings of arbitrary size in the message tree. |
ok, good point, but it does that in a very very interesting way:
At each and any occurence of "]" (within the (payload) data) ... and remember the CDATA-Section is closed with "]]>"
It is hard for me to not see a correlation between the two( "]" and "]]").
| kimbert wrote: |
| Does your ESQL cope with this? |
No. We changed it! Seems to work, thanks
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
