You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by Adam Megacz <ad...@megacz.com> on 2002/08/18 02:54:46 UTC
org.apache.xmlrpc.XmlWriter emits invalid XML
According to XML 1.0, a CDATA section may contain only:
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
[#x10000-#x10FFFF]
http://www.w3.org/TR/2000/REC-xml-20001006#charsets
XmlWriter fails to &#XXXX;-encode characters below 0x20, and emits XML
which is unparseable by most XML parsers.
The following patch fixes this bug.
- a
Index: src/java/org/apache/xmlrpc/XmlWriter.java
===================================================================
RCS file: /home/cvspublic/xml-rpc/src/java/org/apache/xmlrpc/XmlWriter.java,v
retrieving revision 1.2
diff -u -r1.2 XmlWriter.java
--- src/java/org/apache/xmlrpc/XmlWriter.java 8 Aug 2002 21:31:50 -0000 1.2
+++ src/java/org/apache/xmlrpc/XmlWriter.java 18 Aug 2002 00:51:13 -0000
@@ -305,6 +305,11 @@
char c = text.charAt (i);
switch (c)
{
+ case '\t':
+ case '\r':
+ case '\n':
+ write(c);
+ break;
case '<':
write(LESS_THAN_ENTITY);
break;
@@ -315,7 +320,13 @@
write(AMPERSAND_ENTITY);
break;
default:
- write(c);
+ if (c < 0x20 || c > 0xff) {
+ write("&#");
+ write(String.valueOf((int)c));
+ write(";");
+ } else {
+ write(c);
+ }
}
}
}
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Adam Megacz" <ad...@megacz.com>
To: <rp...@xml.apache.org>
Sent: Monday, August 19, 2002 11:27 PM
Subject: Re: org.apache.xmlrpc.XmlWriter emits invalid XML
[snip]
> behavior -- there is no way to send non-ASCII characters within the
> bounds of the spec without using the <unicode> element.
Yes there is.
Any Unicode character allowed in an XML document and having a value greater
than 127 can be encoded as &#XXXX;. It is possible to represent any well
formed XML document in USACII (or EBCDIC for that matter).
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: Making Invoker public?
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Kevin Hester <ke...@ispiri.com> writes:
> Hi,
Hi Kevin.
> Yesterday I began using the Apache XML-RPC library, and I must give praise:
> This is a great library - it works well and it is very cleanly constructed.
> However, I have run into one issue and I'd like to see if you want my fix.
>
> I have a number of objects which are currently using RMI, and as such they
> have methods declared as void. I've decided to encapsulate these objects in
> an XML-RPC framework, but I would still like to have the option of using RMI.
> Everything works great except that the void functions return null when
> invoked through the introspection API.
>
> It seemed to me that creating a glue class that implements the XmlRpcHandler
> and uses introspection would be an ideal solution to this problem. The glue
> class could invoke the method on its target object, check for null return
> value and substitute a value which is acceptable in XML-RPC land (i.e.
> Integer(0)).
This sounds like a nice extension. I'm not sure it's something that
we want on by default, but I wouldn't be against finding some way to
include it in the package.
> Of course, the glue class I'm describing is only a slight modification of
> Invoker.
>
> My solution: Make the invoker class public so that users can subclass it for
> custom behavior. In my case, I override execute to check for a null return
> value.
Andrew Evers is currently working on refactoring the XmlRpcServer
class, splitting on its child classes and making it more reusable. It
would be terrific if you could grab this small chunk of the work which
he has proposed. See his recent message for details:
http://archives.apache.org/eyebrowse/ReadMsg?listName=rpc-dev@xml.apache.org&msgNo=227
> My question to all:
>
> 1) Does this seem like a good solution? It sure seems better than people
> having to reinvent the introspection glue.
Yeah, sounds useful.
> 2) Do you want diffs for this minor change?
I defer to Andrew. You guys can work it out. :-)
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Making Invoker public?
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Kevin Hester <ke...@ispiri.com> writes:
> Hi,
Hi Kevin.
> Yesterday I began using the Apache XML-RPC library, and I must give praise:
> This is a great library - it works well and it is very cleanly constructed.
> However, I have run into one issue and I'd like to see if you want my fix.
>
> I have a number of objects which are currently using RMI, and as such they
> have methods declared as void. I've decided to encapsulate these objects in
> an XML-RPC framework, but I would still like to have the option of using RMI.
> Everything works great except that the void functions return null when
> invoked through the introspection API.
>
> It seemed to me that creating a glue class that implements the XmlRpcHandler
> and uses introspection would be an ideal solution to this problem. The glue
> class could invoke the method on its target object, check for null return
> value and substitute a value which is acceptable in XML-RPC land (i.e.
> Integer(0)).
This sounds like a nice extension. I'm not sure it's something that
we want on by default, but I wouldn't be against finding some way to
include it in the package.
> Of course, the glue class I'm describing is only a slight modification of
> Invoker.
>
> My solution: Make the invoker class public so that users can subclass it for
> custom behavior. In my case, I override execute to check for a null return
> value.
Andrew Evers is currently working on refactoring the XmlRpcServer
class, splitting on its child classes and making it more reusable. It
would be terrific if you could grab this small chunk of the work which
he has proposed. See his recent message for details:
http://archives.apache.org/eyebrowse/ReadMsg?listName=rpc-dev@xml.apache.org&msgNo=227
> My question to all:
>
> 1) Does this seem like a good solution? It sure seems better than people
> having to reinvent the introspection glue.
Yeah, sounds useful.
> 2) Do you want diffs for this minor change?
I defer to Andrew. You guys can work it out. :-)
--
Daniel Rall <dl...@finemaltcoding.com>
Making Invoker public?
Posted by Kevin Hester <ke...@ispiri.com>.
Hi,
Yesterday I began using the Apache XML-RPC library, and I must give praise:
This is a great library - it works well and it is very cleanly constructed.
However, I have run into one issue and I'd like to see if you want my fix.
I have a number of objects which are currently using RMI, and as such they
have methods declared as void. I've decided to encapsulate these objects in
an XML-RPC framework, but I would still like to have the option of using RMI.
Everything works great except that the void functions return null when
invoked through the introspection API.
It seemed to me that creating a glue class that implements the XmlRpcHandler
and uses introspection would be an ideal solution to this problem. The glue
class could invoke the method on its target object, check for null return
value and substitute a value which is acceptable in XML-RPC land (i.e.
Integer(0)).
Of course, the glue class I'm describing is only a slight modification of
Invoker.
My solution: Make the invoker class public so that users can subclass it for
custom behavior. In my case, I override execute to check for a null return
value.
My question to all:
1) Does this seem like a good solution? It sure seems better than people
having to reinvent the introspection glue.
2) Do you want diffs for this minor change?
Kevin
--
Kevin Hester
kevinh@ispiri.com Ispiri Development
Making Invoker public?
Posted by Kevin Hester <ke...@ispiri.com>.
Hi,
Yesterday I began using the Apache XML-RPC library, and I must give praise:
This is a great library - it works well and it is very cleanly constructed.
However, I have run into one issue and I'd like to see if you want my fix.
I have a number of objects which are currently using RMI, and as such they
have methods declared as void. I've decided to encapsulate these objects in
an XML-RPC framework, but I would still like to have the option of using RMI.
Everything works great except that the void functions return null when
invoked through the introspection API.
It seemed to me that creating a glue class that implements the XmlRpcHandler
and uses introspection would be an ideal solution to this problem. The glue
class could invoke the method on its target object, check for null return
value and substitute a value which is acceptable in XML-RPC land (i.e.
Integer(0)).
Of course, the glue class I'm describing is only a slight modification of
Invoker.
My solution: Make the invoker class public so that users can subclass it for
custom behavior. In my case, I override execute to check for a null return
value.
My question to all:
1) Does this seem like a good solution? It sure seems better than people
having to reinvent the introspection glue.
2) Do you want diffs for this minor change?
Kevin
--
Kevin Hester
kevinh@ispiri.com Ispiri Development
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Adam Megacz <ad...@megacz.com> writes:
> Daniel Rall <dl...@finemaltcoding.com> writes:
> > > Personally, I would advocate John's approach, combined with support
> > > for the <unicode> element from the XMC draft:
>
> > Thanks for the offer. I went ahead and just changed the code to throw
> > an XmlRpcException (it's really annoying that that is a checked
> > exception, btw, grrr).
>
> Why not just send it as <unicode>, then? That would eliminate the
> checked exception.
I don't know what XMC is, and don't have the time or inclination to
learn about it.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Adam Megacz <ad...@megacz.com> writes:
> Daniel Rall <dl...@finemaltcoding.com> writes:
> > > Personally, I would advocate John's approach, combined with support
> > > for the <unicode> element from the XMC draft:
>
> > Thanks for the offer. I went ahead and just changed the code to throw
> > an XmlRpcException (it's really annoying that that is a checked
> > exception, btw, grrr).
>
> Why not just send it as <unicode>, then? That would eliminate the
> checked exception.
I don't know what XMC is, and don't have the time or inclination to
learn about it.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Adam Megacz <ad...@megacz.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> > Personally, I would advocate John's approach, combined with support
> > for the <unicode> element from the XMC draft:
> Thanks for the offer. I went ahead and just changed the code to throw
> an XmlRpcException (it's really annoying that that is a checked
> exception, btw, grrr).
Why not just send it as <unicode>, then? That would eliminate the
checked exception.
- a
--
Since costs nothing to develop, vaporware offers a better ROI than
anything else (provided your marketing department is good enough).
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Adam Megacz <ad...@megacz.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
> > Personally, I would advocate John's approach, combined with support
> > for the <unicode> element from the XMC draft:
> Thanks for the offer. I went ahead and just changed the code to throw
> an XmlRpcException (it's really annoying that that is a checked
> exception, btw, grrr).
Why not just send it as <unicode>, then? That would eliminate the
checked exception.
- a
--
Since costs nothing to develop, vaporware offers a better ROI than
anything else (provided your marketing department is good enough).
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Adam Megacz <ad...@megacz.com> writes:
> > > These characters are not allowed even if they are encoded as &#XXXX;
> > > The only correct behaviour is to refuse to handle data containing these
> > > characters.
>
> > So rather than entity encoding the characters, an XmlRpcException of
> > some sort should be thrown?
>
> Ah, the joys of the self-contradictory XML-RPC spec ;)
>
> "<string> [is an] ASCII string"
>
> "Any characters are allowed in a string except < and &... A string can
> be used to encode binary data."
>
> Dave absolutely refuses to fix or clarify this.
>
> Personally, I would advocate John's approach, combined with support
> for the <unicode> element from the XMC draft:
>
> http://www.xwt.org/xmc/draft-megacz-xmc-06.txt
>
> If the other end can't understand <unicode>, it will fault. Non-ASCII
> characters aren't allowed under XML-RPC, so a fault is the desired
> behavior -- there is no way to send non-ASCII characters within the
> bounds of the spec without using the <unicode> element.
>
> I can write up a patch for this if you like.
Thanks for the offer. I went ahead and just changed the code to throw
an XmlRpcException (it's really annoying that that is a checked
exception, btw, grrr).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Adam Megacz" <ad...@megacz.com>
To: <rp...@xml.apache.org>
Sent: Monday, August 19, 2002 11:27 PM
Subject: Re: org.apache.xmlrpc.XmlWriter emits invalid XML
[snip]
> behavior -- there is no way to send non-ASCII characters within the
> bounds of the spec without using the <unicode> element.
Yes there is.
Any Unicode character allowed in an XML document and having a value greater
than 127 can be encoded as &#XXXX;. It is possible to represent any well
formed XML document in USACII (or EBCDIC for that matter).
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Adam Megacz <ad...@megacz.com> writes:
> > > These characters are not allowed even if they are encoded as &#XXXX;
> > > The only correct behaviour is to refuse to handle data containing these
> > > characters.
>
> > So rather than entity encoding the characters, an XmlRpcException of
> > some sort should be thrown?
>
> Ah, the joys of the self-contradictory XML-RPC spec ;)
>
> "<string> [is an] ASCII string"
>
> "Any characters are allowed in a string except < and &... A string can
> be used to encode binary data."
>
> Dave absolutely refuses to fix or clarify this.
>
> Personally, I would advocate John's approach, combined with support
> for the <unicode> element from the XMC draft:
>
> http://www.xwt.org/xmc/draft-megacz-xmc-06.txt
>
> If the other end can't understand <unicode>, it will fault. Non-ASCII
> characters aren't allowed under XML-RPC, so a fault is the desired
> behavior -- there is no way to send non-ASCII characters within the
> bounds of the spec without using the <unicode> element.
>
> I can write up a patch for this if you like.
Thanks for the offer. I went ahead and just changed the code to throw
an XmlRpcException (it's really annoying that that is a checked
exception, btw, grrr).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Adam Megacz <ad...@megacz.com>.
> > These characters are not allowed even if they are encoded as &#XXXX;
> > The only correct behaviour is to refuse to handle data containing these
> > characters.
> So rather than entity encoding the characters, an XmlRpcException of
> some sort should be thrown?
Ah, the joys of the self-contradictory XML-RPC spec ;)
"<string> [is an] ASCII string"
"Any characters are allowed in a string except < and &... A string can
be used to encode binary data."
Dave absolutely refuses to fix or clarify this.
Personally, I would advocate John's approach, combined with support
for the <unicode> element from the XMC draft:
http://www.xwt.org/xmc/draft-megacz-xmc-06.txt
If the other end can't understand <unicode>, it will fault. Non-ASCII
characters aren't allowed under XML-RPC, so a fault is the desired
behavior -- there is no way to send non-ASCII characters within the
bounds of the spec without using the <unicode> element.
I can write up a patch for this if you like.
- a
--
Sick of HTML user interfaces?
www.xwt.org
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Monday, August 19, 2002 11:05 PM
Subject: Re: org.apache.xmlrpc.XmlWriter emits invalid XML
[snip]
> > The production you quote is applied after any numeric character
reference is
> > converted into a character.
> >
> > http://www.xml.com/axml/axml.html
>
> So rather than entity encoding the characters, an XmlRpcException of
> some sort should be thrown?
Yes, that's all that can be done if we want to meet the letter of the XML
spec.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: <rp...@xml.apache.org>
Sent: Monday, August 19, 2002 11:05 PM
Subject: Re: org.apache.xmlrpc.XmlWriter emits invalid XML
[snip]
> > The production you quote is applied after any numeric character
reference is
> > converted into a character.
> >
> > http://www.xml.com/axml/axml.html
>
> So rather than entity encoding the characters, an XmlRpcException of
> some sort should be thrown?
Yes, that's all that can be done if we want to meet the letter of the XML
spec.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Adam Megacz <ad...@megacz.com>.
> > These characters are not allowed even if they are encoded as &#XXXX;
> > The only correct behaviour is to refuse to handle data containing these
> > characters.
> So rather than entity encoding the characters, an XmlRpcException of
> some sort should be thrown?
Ah, the joys of the self-contradictory XML-RPC spec ;)
"<string> [is an] ASCII string"
"Any characters are allowed in a string except < and &... A string can
be used to encode binary data."
Dave absolutely refuses to fix or clarify this.
Personally, I would advocate John's approach, combined with support
for the <unicode> element from the XMC draft:
http://www.xwt.org/xmc/draft-megacz-xmc-06.txt
If the other end can't understand <unicode>, it will fault. Non-ASCII
characters aren't allowed under XML-RPC, so a fault is the desired
behavior -- there is no way to send non-ASCII characters within the
bounds of the spec without using the <unicode> element.
I can write up a patch for this if you like.
- a
--
Sick of HTML user interfaces?
www.xwt.org
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
> ----- Original Message -----
> From: "Adam Megacz" <ad...@megacz.com>
> To: <rp...@xml.apache.org>
> Sent: Sunday, August 18, 2002 1:54 AM
> Subject: org.apache.xmlrpc.XmlWriter emits invalid XML
>
>
> >
> > According to XML 1.0, a CDATA section may contain only:
> >
> > [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
> > [#x10000-#x10FFFF]
> >
> > http://www.w3.org/TR/2000/REC-xml-20001006#charsets
> >
> > XmlWriter fails to &#XXXX;-encode characters below 0x20, and emits XML
> > which is unparseable by most XML parsers.
> >
> > The following patch fixes this bug.
>
> Unfortunately this doesn't fix the problem.
>
> These characters are not allowed even if they are encoded as &#XXXX;
>
> The only correct behaviour is to refuse to handle data containing these
> characters.
>
> The production you quote is applied after any numeric character reference is
> converted into a character.
>
> http://www.xml.com/axml/axml.html
So rather than entity encoding the characters, an XmlRpcException of
some sort should be thrown?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"John Wilson" <tu...@wilson.co.uk> writes:
> ----- Original Message -----
> From: "Adam Megacz" <ad...@megacz.com>
> To: <rp...@xml.apache.org>
> Sent: Sunday, August 18, 2002 1:54 AM
> Subject: org.apache.xmlrpc.XmlWriter emits invalid XML
>
>
> >
> > According to XML 1.0, a CDATA section may contain only:
> >
> > [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
> > [#x10000-#x10FFFF]
> >
> > http://www.w3.org/TR/2000/REC-xml-20001006#charsets
> >
> > XmlWriter fails to &#XXXX;-encode characters below 0x20, and emits XML
> > which is unparseable by most XML parsers.
> >
> > The following patch fixes this bug.
>
> Unfortunately this doesn't fix the problem.
>
> These characters are not allowed even if they are encoded as &#XXXX;
>
> The only correct behaviour is to refuse to handle data containing these
> characters.
>
> The production you quote is applied after any numeric character reference is
> converted into a character.
>
> http://www.xml.com/axml/axml.html
So rather than entity encoding the characters, an XmlRpcException of
some sort should be thrown?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Adam Megacz" <ad...@megacz.com>
To: <rp...@xml.apache.org>
Sent: Sunday, August 18, 2002 1:54 AM
Subject: org.apache.xmlrpc.XmlWriter emits invalid XML
>
> According to XML 1.0, a CDATA section may contain only:
>
> [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
> [#x10000-#x10FFFF]
>
> http://www.w3.org/TR/2000/REC-xml-20001006#charsets
>
> XmlWriter fails to &#XXXX;-encode characters below 0x20, and emits XML
> which is unparseable by most XML parsers.
>
> The following patch fixes this bug.
Unfortunately this doesn't fix the problem.
These characters are not allowed even if they are encoded as &#XXXX;
The only correct behaviour is to refuse to handle data containing these
characters.
The production you quote is applied after any numeric character reference is
converted into a character.
http://www.xml.com/axml/axml.html
Re: org.apache.xmlrpc.XmlWriter emits invalid XML
Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Adam Megacz" <ad...@megacz.com>
To: <rp...@xml.apache.org>
Sent: Sunday, August 18, 2002 1:54 AM
Subject: org.apache.xmlrpc.XmlWriter emits invalid XML
>
> According to XML 1.0, a CDATA section may contain only:
>
> [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |
> [#x10000-#x10FFFF]
>
> http://www.w3.org/TR/2000/REC-xml-20001006#charsets
>
> XmlWriter fails to &#XXXX;-encode characters below 0x20, and emits XML
> which is unparseable by most XML parsers.
>
> The following patch fixes this bug.
Unfortunately this doesn't fix the problem.
These characters are not allowed even if they are encoded as &#XXXX;
The only correct behaviour is to refuse to handle data containing these
characters.
The production you quote is applied after any numeric character reference is
converted into a character.
http://www.xml.com/axml/axml.html