You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by no...@jeppesen.com on 2004/10/22 20:39:33 UTC
RE: XMLUtils does not encode FF / 0xC character in Java Strings...
I understand that... the whole point of xmlEncodeString (as I understand
it) is to encode these characters so they can be sent... am I wrong?
Isn't the point of BeanSerializer / Java2WSDL and back to hide some of the
complexity here? The same string being encoded had regular line-breaks
(\r) as well as a large snippet of xml (with quotes, <,>,etc...).
Once I encode the '\f' as , the AXIS client correctly decodes this as
the '\f' on the client side... am I missing something? This seems like a
good thing.
Thanks,
Noah
"Simon Fell" <sf...@salesforce.com>
10/22/2004 11:34 AM
Please respond to
axis-dev@ws.apache.org
To
<ax...@ws.apache.org>
cc
Subject
RE: XMLUtils does not encode FF / 0xC character in Java Strings...
That doesn't help, the characters that are illegal in XML are illegal
regardless of how they are represented  is still an invalid xml
character reference.
Cheers
Simon
From: noah.fiedel@jeppesen.com [mailto:noah.fiedel@jeppesen.com]
Sent: Friday, October 22, 2004 11:27 AM
To: axis-dev@ws.apache.org
Subject: XMLUtils does not encode FF / 0xC character in Java Strings...
Hi,
I am developing an AXIS/SOAP interface to a legacy system. A
java-bean sent via soap includes a java.lang.String that often contains
FormFeeds/FF/0xC. This is causing a parse error on the client side, with
"invalid xml character... 0xc".
The class org.apache.axis. XMLUtils' method xmlEncodeString is
the method used by the standard/default BeanSerializer to encode Java
Strings. I would think it a good goal of AXIS to support Java Strings
without limiting the characters that could be in those strings... I'm not
sure the full set of special characters that need to be checked for
(possibly this is why the FF character missed the implementation this
far) but am pretty sure that other developers working w/legacy systems
will run into this problem as well.
The main classes that (IMHO) need modification are:
org.apache.axis.utils.XMLUtils
<method: public static String xmlEncodeString(String
orig >
and possibly (I'm not sure what exactly this class does)
org.apache.axis.utils.XMLChar
<static int int charRange[], possibly other methods>
I've already implemented a workaround as I'm on a tight
production schedule, so am not asking anyone for 'help', but think fixing
this bug will help the AXIS community. The workaround
Thanks,
Noah
The additional bit of code:
case '\f' : sBuf.append("");
break;
Note: I think there is another bug in XMLUtils.java, that even though the
'\r' character is recognized for encoding, it is not checked for in the
above section that determines the bool 'needsEncoding':
switch(chars[i]) {
case '&': case '"': case '\'': case '<': case '>': //*****
where is the check for \r, or any others needed (i.e. if '\f' gets
added)?
needsEncoding = true;