Email box closing - Re: Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
[PATCH] Setting SAX features for XML-RPC
I should of course attach the patch as well, sorry.
This is the first time I'm submitting a patch, so I'm hoping this is the
right way to do it.
In our use of XML-RPC we have discovered a security issue regarding the
use of external entities in XML. By creating a custom XML message and
sending it to the XML-RPC handling service it is possible to get the
contents of files stored on the server's file system as part of the
response. The way we would like to solve this is to set the features
http://xml.org/sax/features/external-general-entities and
http://xml.org/sax/features/external-parameter-entities to false for the
SAX parser. However we have not been able to find a way to set this
since we can't get hold of the parser object. The solution we propose is
to add a way to set features in the org.apache.xmlrpc.util.SAXParsers
class. The features set here will be used for all XMLReaders created
through subsequent calls to SAXParsers.newXMLReader(). This modification
will not affect any existing application since if the setFeature()
method in the SAXParsers class isn't used nothing will happen. The patch
file (created using svn diff) is attached to this post.
Best regards
Johan Hägre
Index: SAXParsers.java
===
--- SAXParsers.java (revision 905923)
+++ SAXParsers.java (arbetskopia)
@@ -23,6 +23,8 @@
import org.apache.xmlrpc.XmlRpcException;
import org.xml.sax.SAXException;
+import org.xml.sax.SAXNotRecognizedException;
+import org.xml.sax.SAXNotSupportedException;
import org.xml.sax.XMLReader;
@@ -36,6 +38,14 @@
spf.setValidating(false);
}
+ public static void setFeature(String pName, boolean pValue) throws
SAXNotRecognizedException, SAXNotSupportedException,
ParserConfigurationException {
+ spf.setFeature(pName, pValue);
+ }
+
+ public static boolean getFeature(String pName) throws
SAXNotRecognizedException, SAXNotSupportedException,
ParserConfigurationException {
+ return spf.getFeature(pName);
+ }
+
/** Creates a new instance of {...@link XMLReader}.
*/
public static XMLReader newXMLReader() throws XmlRpcException {
[PATCH] Setting SAX features for XML-RPC
This is the first time I'm submitting a patch, so I'm hoping this is the right way to do it. In our use of XML-RPC we have discovered a security issue regarding the use of external entities in XML. By creating a custom XML message and sending it to the XML-RPC handling service it is possible to get the contents of files stored on the server's file system as part of the response. The way we would like to solve this is to set the features http://xml.org/sax/features/external-general-entities and http://xml.org/sax/features/external-parameter-entities to false for the SAX parser. However we have not been able to find a way to set this since we can't get hold of the parser object. The solution we propose is to add a way to set features in the org.apache.xmlrpc.util.SAXParsers class. The features set here will be used for all XMLReaders created through subsequent calls to SAXParsers.newXMLReader(). This modification will not affect any existing application since if the setFeature() method in the SAXParsers class isn't used nothing will happen. The patch file (created using svn diff) is attached to this post. Best regards Johan Hägre
Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: Email box closing - Re: Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Email box closing - Re: Email box closing - Re: Email box closing - Re: Email box closing - Re: Email box closing - Re: [PATCH] Setting SAX features for XML-RPC
Thanks for your message, however ... Sorry but I'm closing this email box down and will not be checking email sent to it any longer. If this was a genuine email then please update your email address for me to jamie[dot]howard[at]web-engineer[dot]co[dot]uk and resend your message, otherwise I cannot guarantee your message will be read. Sorry for any inconvenience, kind regards //Jamie Howard
Re: [PATCH] Setting SAX features for XML-RPC
Hi, Johan,
lets distinguish between two different questions:
- Whether there is a security issue. If so, this is of course of
general interest and ought to be fixed immediately.
I can imagine that you include an external entity into the clients
message. I can also imagine that this adds a local files contents to
the request. However, I have difficulties to understand why this
should become a part of the response? Is this specific to your
application?
- Whether and how you'd like to access the SAX parser.
Give me a few days to think about this.
Jochen
On Wed, Feb 3, 2010 at 11:23 AM, Johan Hägre johan.ha...@home.se wrote:
I should of course attach the patch as well, sorry.
This is the first time I'm submitting a patch, so I'm hoping this is the
right way to do it.
In our use of XML-RPC we have discovered a security issue regarding the use
of external entities in XML. By creating a custom XML message and sending it
to the XML-RPC handling service it is possible to get the contents of files
stored on the server's file system as part of the response. The way we would
like to solve this is to set the features
http://xml.org/sax/features/external-general-entities and
http://xml.org/sax/features/external-parameter-entities to false for the SAX
parser. However we have not been able to find a way to set this since we
can't get hold of the parser object. The solution we propose is to add a way
to set features in the org.apache.xmlrpc.util.SAXParsers class. The features
set here will be used for all XMLReaders created through subsequent calls to
SAXParsers.newXMLReader(). This modification will not affect any existing
application since if the setFeature() method in the SAXParsers class isn't
used nothing will happen. The patch file (created using svn diff) is
attached to this post.
Best regards
Johan Hägre
Index: SAXParsers.java
===
--- SAXParsers.java (revision 905923)
+++ SAXParsers.java (arbetskopia)
@@ -23,6 +23,8 @@
import org.apache.xmlrpc.XmlRpcException;
import org.xml.sax.SAXException;
+import org.xml.sax.SAXNotRecognizedException;
+import org.xml.sax.SAXNotSupportedException;
import org.xml.sax.XMLReader;
@@ -36,6 +38,14 @@
spf.setValidating(false);
}
+ public static void setFeature(String pName, boolean pValue) throws
SAXNotRecognizedException, SAXNotSupportedException,
ParserConfigurationException {
+ spf.setFeature(pName, pValue);
+ }
+
+ public static boolean getFeature(String pName) throws
SAXNotRecognizedException, SAXNotSupportedException,
ParserConfigurationException {
+ return spf.getFeature(pName);
+ }
+
/** Creates a new instance of {...@link XMLReader}.
*/
public static XMLReader newXMLReader() throws XmlRpcException {
--
Germanys national anthem is the most boring in the world - how telling!
Re: [PATCH] Setting SAX features for XML-RPC
Hello Jochen,
In our application there is definitely a security issue, and I know for
a fact that it can be solved by setting the features
http://xml.org/sax/features/external-general-entities and
http://xml.org/sax/features/external-parameter-entities to false for the
SAX parser (I have tested it). I have provided a patch for the
org.apache.xmlrpc.util.SAXParsers class, unfortunately I forgot to
attach it to my first mail, if you haven't received it I'll attach it to
this mail as well.
By including the external entity inside a i4 element like this:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE OBJECTS [!ENTITY test SYSTEM c:\boot.ini]
...
i49701test;/i4
...
It will cause a number format exception when trying to parse the text
9701test; as an integer (I believe this exception is thrown by
org.apache.xmlrpc.server.XmlRpcStreamServer.getRequest, please see the
attached stack trace). The reason it becomes a security issue for us is
that we send back an error response that includes the error message from
the exception (see attachment). Whether this information should be
included in the response or not is maybe debatable but I'm sure we are
not the only ones including this kind of information in the response and
because of this I think it is a security issue. In this example I have
used c:\boot.ini as the exposed file, and it may not be so sensitive
but I'm sure that for instance c:\program
files\tomcat\conf\tomcat-users.xml would be a much more interesting file.
The patch I have suggested doesn't affect anyone who doesn't like to use
the new functionality and I have a hard time seeing the harm in letting
developers set features for the SAX parser used by XML-RPC.
Best regards
Johan
Jochen Wiedmann wrote:
Hi, Johan,
lets distinguish between two different questions:
- Whether there is a security issue. If so, this is of course of
general interest and ought to be fixed immediately.
I can imagine that you include an external entity into the clients
message. I can also imagine that this adds a local files contents to
the request. However, I have difficulties to understand why this
should become a part of the response? Is this specific to your
application?
- Whether and how you'd like to access the SAX parser.
Give me a few days to think about this.
Jochen
On Wed, Feb 3, 2010 at 11:23 AM, Johan Hägre johan.ha...@home.se wrote:
I should of course attach the patch as well, sorry.
This is the first time I'm submitting a patch, so I'm hoping this is the
right way to do it.
In our use of XML-RPC we have discovered a security issue regarding the use
of external entities in XML. By creating a custom XML message and sending it
to the XML-RPC handling service it is possible to get the contents of files
stored on the server's file system as part of the response. The way we would
like to solve this is to set the features
http://xml.org/sax/features/external-general-entities and
http://xml.org/sax/features/external-parameter-entities to false for the SAX
parser. However we have not been able to find a way to set this since we
can't get hold of the parser object. The solution we propose is to add a way
to set features in the org.apache.xmlrpc.util.SAXParsers class. The features
set here will be used for all XMLReaders created through subsequent calls to
SAXParsers.newXMLReader(). This modification will not affect any existing
application since if the setFeature() method in the SAXParsers class isn't
used nothing will happen. The patch file (created using svn diff) is
attached to this post.
Best regards
Johan Hägre
Index: SAXParsers.java
===
--- SAXParsers.java (revision 905923)
+++ SAXParsers.java (arbetskopia)
@@ -23,6 +23,8 @@
import org.apache.xmlrpc.XmlRpcException;
import org.xml.sax.SAXException;
+import org.xml.sax.SAXNotRecognizedException;
+import org.xml.sax.SAXNotSupportedException;
import org.xml.sax.XMLReader;
@@ -36,6 +38,14 @@
spf.setValidating(false);
}
+ public static void setFeature(String pName, boolean pValue) throws
SAXNotRecognizedException, SAXNotSupportedException,
ParserConfigurationException {
+ spf.setFeature(pName, pValue);
+ }
+
+ public static boolean getFeature(String pName) throws
SAXNotRecognizedException, SAXNotSupportedException,
ParserConfigurationException {
+ return spf.getFeature(pName);
+ }
+
/** Creates a new instance of {...@link XMLReader}.
*/
public static XMLReader newXMLReader() throws XmlRpcException {
2010-02-03 16:30:05,687 ERROR http-8443-Processor25
org.apache.xmlrpc.server.XmlRpcErrorLogger - Failed to parse XML-RPC request:
Failed to parse integer value: 9701[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Professional
Re: [PATCH] Setting SAX features for XML-RPC
On 3 Feb 2010, at 12:43, Jochen Wiedmann wrote: Hi, Johan, lets distinguish between two different questions: - Whether there is a security issue. If so, this is of course of general interest and ought to be fixed immediately. I can imagine that you include an external entity into the clients message. I can also imagine that this adds a local files contents to the request. However, I have difficulties to understand why this should become a part of the response? Is this specific to your application? - Whether and how you'd like to access the SAX parser. Give me a few days to think about this. I believe Johan is quite right about this being a security issue. It's not a new issue, it was raised on XML-DEV many years ago as a generic security problem with XML parsers. It was an issue when Apache XML-RPC was still Helma XML-RPC and was (I think) one of the reasons for standardising on MinML as the default parser (as that does not allow DTDs). It's also one of the reasons why SOAP doesn't allow DTDs. My own view is that both these features should be set false by default. John Wilson
[PATCH] Faq: ClassCastException
Hi Jochen, here is my first patch ;-) I think the cast in the faq would cause ClassCastException and should be omitted. Regards Stano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ThreadPool race condition
On Feb 1, 2008, at 4:07 PM, Dave Glowacki wrote:
I seem to have turned up a race condition in the ThreadPool class.
I was running the latest xmlrpc (from Subversion) under the JRockit
JVM on a multicore machine and the XML-RPC server was locking up.
I eventually tracked it down to these two bits of code:
public void run() {
while (!isShuttingDown()) {
final Task t = getTask();
if (t == null) {
try {
synchronized (this) {
wait();
}
and:
synchronized void start(Task pTask) {
task = pTask;
synchronized (thread) {
thread.notify();
}
}
The first bit of code is run by a newly created thread, while the
second bit of code is run in the original thread. As far as I can
tell, JRockit did the following:
1) the new Thread started up, called getTask() and got back null.
2) the original thread ran the entire start() method, assigning
'task' and calling thread.notify()
3) the new Thread then entered the 'synchronized' block and did the
wait(), but since the notify() was already called, it never wakes up
I've attached a patch which fixed the problem for me.xml.patch
Actually, further testing reveals that my fix is susceptible to a
deadlock. I'll try to come up with a better fix...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] ThreadPool race condition
I seem to have turned up a race condition in the ThreadPool class.
I was running the latest xmlrpc (from Subversion) under the JRockit
JVM on a multicore machine and the XML-RPC server was locking up. I
eventually tracked it down to these two bits of code:
public void run() {
while (!isShuttingDown()) {
final Task t = getTask();
if (t == null) {
try {
synchronized (this) {
wait();
}
and:
synchronized void start(Task pTask) {
task = pTask;
synchronized (thread) {
thread.notify();
}
}
The first bit of code is run by a newly created thread, while the
second bit of code is run in the original thread. As far as I can
tell, JRockit did the following:
1) the new Thread started up, called getTask() and got back null.
2) the original thread ran the entire start() method, assigning
'task' and calling thread.notify()
3) the new Thread then entered the 'synchronized' block and did the
wait(), but since the notify() was already called, it never wakes up
I've attached a patch which fixed the problem for me.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH]
Bug in current version (07/14/2006).
class - org.apache.xmlrpc.server.ReflectiveXmlRpcHandler
bug in the method :
public Object execute(XmlRpcRequest pRequest) throws XmlRpcException
{
AuthenticationHandler authHandler =
mapping.getAuthenticationHandler();
if (authHandler != null
!authHandler.isAuthorized(pRequest)) {
throw new XmlRpcNotAuthorizedException(Not authorized);
}
Object[] args = new Object[pRequest.getParameterCount()];
for (int j = 0; j args.length; j++) {
args[j] = pRequest.getParameter(j);
}
Object instance = getInstance(pRequest);
for (int i = 0; i methods.length; i++) {
MethodData methodData = methods[i];
TypeConverter[] converters = methodData.typeConverters;
if (args.length == converters.length) {
boolean matching = true;
for (int j = 0; j args.length; j++) {
// As is:
//if (!converters[j].isConvertable(args[i])) {
// As should be:
if (!converters[j].isConvertable(args[j])) {
matching = false;
break;
}
}
if (matching) {
for (int j = 0; j args.length; j++) {
args[i] = converters[i].convert(args[i]);
}
return invoke(instance, methodData.method, args);
}
}
}
throw new XmlRpcException(No method matching arguments: +
Util.getSignature(args));
}
Hope it helps ...
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (XMLRPC-85) CLONE -Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient
[ http://issues.apache.org/jira/browse/XMLRPC-85?page=all ] Jochen Wiedmann closed XMLRPC-85: - Resolution: Won't Fix As discussed on the mailing list, I do not like this feature. I have recommended that you ask other developers, but noone else has volunteered to pull the patch in. Consequently, I am closing the issue. CLONE -Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient -- Key: XMLRPC-85 URL: http://issues.apache.org/jira/browse/XMLRPC-85 Project: XML-RPC Type: Bug Components: Source Versions: 1.2 Environment: Operating System: Other Platform: Other Reporter: Danny Angus I submitted a patch to the dev list in december, it appears to have been forgotten. See: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=rpc- [EMAIL PROTECTED]msgNo=530 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH]
NullPointerException from the server on multicall when calling a method with no arg using xmlrpc++ C++ library with xmlrpc-2.0. This is because the xmlrpc++ client does not send the params field, whitch is of no use in this case. Here is a patch in the MultiCall class, that can resolve this problem. dwzr MultiCall.java Description: application/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-85) CLONE -Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient
[
http://issues.apache.org/jira/browse/XMLRPC-85?page=comments#action_12413091 ]
Danny Angus commented on XMLRPC-85:
---
After discussion with users and a look at mail archives it would appear that
this patch, had it been applied, would have resolved a number of users' issues.
There is also still support for having it applied by users on the users list.
XMLRPC-27 has been closed so I am opening this clone to request that this patch
actually be applied and not discarded.
Index: XmlRpcClient.java
===
RCS file: /home/cvspublic/xml-rpc/src/java/org/apache/xmlrpc/XmlRpcClient.java,v
retrieving revision 1.14
diff -u -r1.14 XmlRpcClient.java
--- XmlRpcClient.java 21 Nov 2002 01:28:16 - 1.14
+++ XmlRpcClient.java 26 Nov 2002 12:18:20 -
@@ -97,6 +97,15 @@
public XmlRpcClient(URL url)
{
this.url = url;
+if(url.getUserInfo()!=null){
+String user = url.getUserInfo();
+int split = user.indexOf(':');
+if (split -1){
+this.setBasicAuthentication(user.substring(0,split),
user.substring(split+1));
+}else{
+this.setBasicAuthentication(user,);
+}
+}
if (XmlRpc.debug)
{
System.out.println(Created client to url space + url);
CLONE -Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied
to XmlRpcClient
--
Key: XMLRPC-85
URL: http://issues.apache.org/jira/browse/XMLRPC-85
Project: XML-RPC
Type: Bug
Components: Source
Versions: 1.2
Environment: Operating System: Other
Platform: Other
Reporter: Danny Angus
I submitted a patch to the dev list in december, it appears to have been
forgotten.
See: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=rpc-
[EMAIL PROTECTED]msgNo=530
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XMLRPC-27) Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient
[ http://issues.apache.org/jira/browse/XMLRPC-27?page=comments#action_12378379 ] Danny Angus commented on XMLRPC-27: --- Well it was a simple ten line addition to the code: http://mail-archives.apache.org/mod_mbox/xml-rpc-dev/200211.mbox/[EMAIL PROTECTED] But no one bothered to apply it. You don't want it but that doesn't mean no one wants it, it is easy to apply but it is also easy to work round. I kind of resent the fact that despite the patch being completely un-controversial you should ignore it for three years and then just choose to reject it like this. It doesn't look good. Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient --- Key: XMLRPC-27 URL: http://issues.apache.org/jira/browse/XMLRPC-27 Project: XML-RPC Type: Bug Components: Source Versions: 1.2 Environment: Operating System: Other Platform: Other Reporter: Danny Angus I submitted a patch to the dev list in december, it appears to have been forgotten. See: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=rpc- [EMAIL PROTECTED]msgNo=530 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: [jira] Geschlossen: (XMLRPC-27) Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient
After waiting three years for this patch to be applied I'd like it to be known that I'm suprised, and not a little disappointed that this issue should be resolved WONTFIX. It is not for me to tell you what you should and shouldn't do, but I would have thought that the Apache way was to review and apply patches, not to ignore them for three years and then reject them without any reason. d. -- Forwarded message -- From: Jochen Wiedmann (JIRA) xmlrpc-dev@ws.apache.org Date: 07-May-2006 22:06 Subject: [jira] Geschlossen: (XMLRPC-27) Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient To: xmlrpc-dev@ws.apache.org [ http://issues.apache.org/jira/browse/XMLRPC-27?page=all ] Jochen Wiedmann closed XMLRPC-27: - Resolution: Won't Fix Assign To: (was: rpc-dev mailing list) The issue has seen no actual activity in more than three years now. Consequently, I assume that there is no true interest in this functionality. Additionally, I for myself do find no reason for an alternative way to specify credentials. I am closing the issue now. Please reopen, if required. Patch to allow protocol://user:[EMAIL PROTECTED] urls to be supplied to XmlRpcClient --- Key: XMLRPC-27 URL: http://issues.apache.org/jira/browse/XMLRPC-27 Project: XML-RPC Type: Bug Components: Source Versions: 1.2 Environment: Operating System: Other Platform: Other Reporter: Danny Angus I submitted a patch to the dev list in december, it appears to have been forgotten. See: http://nagoya.apache.org/eyebrowse/ReadMsg?listName=rpc- [EMAIL PROTECTED]msgNo=530 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (XMLRPC-36) Patch for bug with array or struct in SimpleXmlRpcClient
[ http://issues.apache.org/jira/browse/XMLRPC-36?page=all ]
Daniel Rall reopened XMLRPC-36:
---
Assign To: Daniel Rall
This issue is valid against the 1.2 line.
Patch for bug with array or struct in SimpleXmlRpcClient
Key: XMLRPC-36
URL: http://issues.apache.org/jira/browse/XMLRPC-36
Project: XML-RPC
Type: Bug
Components: Source
Versions: unspecified
Environment: Operating System: All
Platform: All
Reporter: Lee Haslup
Assignee: Daniel Rall
When a Value object is created to accumulate an array or a struct the setType
method creates two objects of the given type. One (referred to by the array
or
struct variable) is used to accumulate the contents. The other (referred to
by
the value variable) is always empty. The (always empty) value object is used
to
construct the result and arrays or structs returned by the client's execute
method are always empty.
The following worked for me...
The method setType in the Value class currently reads...
/**
* Set the type of this value. If it's a container, create the
* corresponding java container.
*/
public void setType(int type)
{
// System.err.println (setting type to +types[type]);
this.type = type;
if (type == ARRAY)
{
value = new Vector();
array = new Vector();
}
if (type == STRUCT)
{
value = new Hashtable();
struct = new Hashtable();
}
}
It probably should read...
/**
* Set the type of this value. If it's a container, create the
* corresponding java container.
*/
public void setType(int type)
{
// System.err.println (setting type to +types[type]);
this.type = type;
if (type == ARRAY)
{
array = new Vector();
value = array;
}
if (type == STRUCT)
{
struct = new Hashtable();
value = struct;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Geschlossen: (XMLRPC-36) Patch for bug with array or struct in SimpleXmlRpcClient
[ http://issues.apache.org/jira/browse/XMLRPC-36?page=all ]
Jochen Wiedmann closed XMLRPC-36:
-
Resolution: Won't Fix
Assign To: (was: rpc-dev mailing list)
Doesn't seem to apply to version 3. Please reopen, if required.
Patch for bug with array or struct in SimpleXmlRpcClient
Key: XMLRPC-36
URL: http://issues.apache.org/jira/browse/XMLRPC-36
Project: XML-RPC
Type: Bug
Components: Source
Versions: unspecified
Environment: Operating System: All
Platform: All
Reporter: Lee Haslup
When a Value object is created to accumulate an array or a struct the setType
method creates two objects of the given type. One (referred to by the array
or
struct variable) is used to accumulate the contents. The other (referred to
by
the value variable) is always empty. The (always empty) value object is used
to
construct the result and arrays or structs returned by the client's execute
method are always empty.
The following worked for me...
The method setType in the Value class currently reads...
/**
* Set the type of this value. If it's a container, create the
* corresponding java container.
*/
public void setType(int type)
{
// System.err.println (setting type to +types[type]);
this.type = type;
if (type == ARRAY)
{
value = new Vector();
array = new Vector();
}
if (type == STRUCT)
{
value = new Hashtable();
struct = new Hashtable();
}
}
It probably should read...
/**
* Set the type of this value. If it's a container, create the
* corresponding java container.
*/
public void setType(int type)
{
// System.err.println (setting type to +types[type]);
this.type = type;
if (type == ARRAY)
{
array = new Vector();
value = array;
}
if (type == STRUCT)
{
struct = new Hashtable();
value = struct;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12368078 ] Jochen Wiedmann commented on XMLRPC-75: --- Walter, I apologize, but I am unhappy with the overloading. While I accept, that it might be suitable in certain situations, I do not think that it should be the default. In particular, I do not think that the selection of the right method via reflection should occur with any method invocation. That's something we had in version 2 and have just successfully managed to get rid of. IMO, the AbstractReflectiveHandlerMapping should support a single method per name only. There is no reason for not adding more complicated subclasses, if you like that. Jochen Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Assignee: Jochen Wiedmann Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Zugewiesen: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=all ] Jochen Wiedmann reassigned XMLRPC-75: - Assign To: Jochen Wiedmann Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Assignee: Jochen Wiedmann Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12367658 ] Jochen Wiedmann commented on XMLRPC-75: --- Walter, I have added the interfaces XmlRpcListableHandlerMapping, and XmlRpcMetaDataHandler. Please note: - I have added some comments. They represent my thoughts. As such, they are questionable. Please read them carefully and verify, whether they meet your expectations. - I have added methods getMethodSignatures() and getMethodHelp() to the handler mapping. Obviously, the will usually be implemented by simply calling the respective handlers methods. However, I find it thinkable, that a handler mapping will not do this. If the above is fine for you, then I suggest the following steps to follow: - Modify your XmlRpcSystemImpl to use the handler mapping methods. (Nice idea, btw, to implement it like this. Did you note, that it can easily be added to the property mappings by simply adding a property system? Dynamic addition isn't required.) - Make the default handler mappings implement listable handler mapping. - Same for the default handlers, which should implement metadada handler. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Assignee: Jochen Wiedmann Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
Jochen Wiedmann (JIRA) wrote: [ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12367658 ] Jochen Wiedmann commented on XMLRPC-75: --- Walter, I have added the interfaces XmlRpcListableHandlerMapping, and XmlRpcMetaDataHandler. Please note: - I have added some comments. They represent my thoughts. As such, they are questionable. Please read them carefully and verify, whether they meet your expectations. Hmm, they seem to be based on the PHP implementation of these methods, and I'm not sure of the meaning of the one describing the expected behavior of system.methodSignature for a non-signature-supporting method. My thought is to just return an empty outer list. Also, should there be a difference between the method does not support X response and the no such method response? I am thinking to return an empty result for the first, and give a fault response (XmlRpcException) for the second. - I have added methods getMethodSignatures() and getMethodHelp() to the handler mapping. Obviously, the will usually be implemented by simply calling the respective handlers methods. However, I find it thinkable, that a handler mapping will not do this. Hmm, I think I see your point, although it does mean adding boilerplate code for any mapping that does the expected thing. If the above is fine for you, then I suggest the following steps to follow: - Modify your XmlRpcSystemImpl to use the handler mapping methods. (Nice idea, btw, to implement it like this. Did you note, that it can easily be added to the property mappings by simply adding a property system? Dynamic addition isn't required.) Actually, because it has no zero-argument constructors, the current PropertyHandlerMapping cannot instantiate it. I'm adding support for passing itself to objects when necessary. - Make the default handler mappings implement listable handler mapping. - Same for the default handlers, which should implement metadata handler. Working on this now.
[jira] Updated: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=all ] Walter Mundt updated XMLRPC-75: --- Attachment: xmlrpc3-metadata.diff Okay, here is an updated patch which uses your interfaces. It also adds support in PropertyHandlerMapping for automatically passing the mapping to the constructor for any object specified in the property file. This could be used to subclass PHM and store additional information used by the various XML-RPC services. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Assignee: Jochen Wiedmann Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12367682 ] Walter Mundt commented on XMLRPC-75: Oh, the patch also adds method overloading support to AbstractReflectiveHandlerMapping, so that, for example, a class that implements both foo(String) and foo(String[]) for some operation can make both versions available via XML-RPC. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Assignee: Jochen Wiedmann Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
Jochen Wiedmann (JIRA) wrote: Walter, are you interested in getting this into the 3.0 branch? I am, but first I have a few issues with the 3.0 branch that I don't like. First and foremost, the capabiliry to expose the methods on particular instances of a class has been removed and replaced with a default-constructor/proerty-file-based API that would be much less convenient for me to use. Specifically, the simple ws.addHandler(name, someRandomObject) mechanism is _very_ handy, and going out to property files is, for my purposes (rapid prototyping and integration of code in different languages) vastly less convenient. Therefore, before I have any interest in workin on the 3.0 branch, you'll have to agree to reinstate the older option of providing arbitrary Object instances at runtime to a handler mapping. I don't care if the call structure changes to ((PropertyHandlerMapping)ws.getXmlRpcServer().getHandlerMapping()).addHandler(name, obj); if that would be preferred, and I will whip up a quick patch to add such a call if you like. - First of all, you should propose necessary extensions for the interfaces handlermapping and handler. (Recommended: Create an interface like XmlRpcMetaDataHandlerMapping, which extends XmlRpcHandlerMapping.) - Second: Make the existing classes implement your new interfaces. - Third: Provide special handlers, which provide the requested metadata. Can do, given the conditions above.
Re: [jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
On 2/23/06, Walter Mundt [EMAIL PROTECTED] wrote: Specifically, the simple ws.addHandler(name, someRandomObject) mechanism is _very_ handy, and going out to property files is, for my purposes (rapid prototyping and integration of code in different languages) vastly less convenient. Therefore, before I have any interest in workin on the 3.0 branch, you'll have to agree to reinstate the older option of providing arbitrary Object instances at runtime to a handler mapping. There is absolutely no reason, that prevents additional implementations of XmlRpcHandlerMapping. Patches welcome. Jochen -- Whenever you find yourself on the side of the majority, it is time to pause and reflect. (Mark Twain)
[jira] Commented: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12367610 ] Walter Mundt commented on XMLRPC-75: Oops! My earlier comment is incorrect. The attached patch _includes_ the changes from XMLRPC-76, sorry. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=all ] Walter Mundt updated XMLRPC-75: --- Attachment: xmlrpc3-metadata.diff Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch, xmlrpc3-metadata.diff, xmlrpc3-metadata.diff I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12367476 ] Jochen Wiedmann commented on XMLRPC-75: --- Walter, are you interested in getting this into the 3.0 branch? If so, let's do it in a few steps. - First of all, you should propose necessary extensions for the interfaces handlermapping and handler. (Recommended: Create an interface like XmlRpcMetaDataHandlerMapping, which extends XmlRpcHandlerMapping.) - Second: Make the existing classes implement your new interfaces. - Third: Provide special handlers, which provide the requested metadata. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12361436 ] Walter Mundt commented on XMLRPC-75: Don't worry about the original patches then, as they're not terrribly relevant -- they're both around 3-4 years old at this point, thus this new attempt. However, this is not just yet another handler mapping. It adds a new interface that custom handlers can implement to support introspection, as well as a new derived Invoker that implements this interface using Java reflection. It also adds a new ContextXmlRpcHandler which makes use of this interface to actually implement the method calls specified by the introspection API, and a function in the SystemHandler to enable those methods if it is so desired. First, I will argue that this is a useful addition to the library. Second, I will argue that this code belongs in the core distribution. For the first point: While introspection is not part of the XML-RPC specification, it is a very useful feature for automatic discovery of services and proxy interface generation, among other things. This particular introspection interface is supported both by the PHP XML-RPC extension here: http://us3.php.net/manual/en/ref.xmlrpc.php and the standard Python XML-RPC server library (although the latter doesn't yet support methodSignature queries automatically). Supporting it here would mean that this library would behave more similarly to other XML-RPC implementations that are available; whether this is desirable in and of itself is debatable, but I think it is if there is no downside to the proposition. For the second: First of all, it's harmless for those who do not wish to take advantage of it. None of the code for actually calling a particular RPC method is changed, so the only possible performance change is (very) slightly larger code size. Second, as I mentioned above, having it bundled increases similarity with other XML-RPC implementations. Third, some changes, that make the introspection API easier to use, such as the new introspection-related methods on the SystemHandler and DefaultHandlerMapping class, and the addition of introspection support to the SystemHandler, could not be implemented as elegantly were the introspection code to be published and maintained separately. Finally, if introspection is not merged into the main source tree, this patch will likely end up out-of-date and useless, just as the previous one did, resulting in people who need introspection support sticking with older versions of the library and being unable to contribute to the project's current code. On the other hand, if it is merged, then it should be fairly easy to see when it breaks and fix it as the changes that require it to be updated are made. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Kommentiert: (XMLRPC-75) Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943)
[ http://issues.apache.org/jira/browse/XMLRPC-75?page=comments#action_12361444 ] Jochen Wiedmann commented on XMLRPC-75: --- From your comment, I conclude that a) there are implementations in other languages, which do similar things and that b) it is based on introspection As for a), I still do miss a description what does happen. The links you mention above are much more generic and no specifications or something similar. As for b), the existing DefaultHandler is based on reflection itself. In other words, I do not have the feeling to know more. Introspection Patch for XML-RPC, current to SVN 2005-12-29 (r359943) Key: XMLRPC-75 URL: http://issues.apache.org/jira/browse/XMLRPC-75 Project: XML-RPC Type: New Feature Components: Source Versions: unspecified Reporter: Walter Mundt Attachments: IntrospectionExample.java, xmlrpc-2.0-beta-introspection.patch I've taken Aaron Hamid's Introspection patch (which was in turn derived from the one here: http://xmlrpc-c.sourceforge.net/hacks/helma-xmlrpc-introspection.diff ) and basically rewritten it to work with the current XML-RPC library. I tried to set it up so that it followed the existing coding style as much as possible, and would not break any existing applications. For example, when I needed a list of handlers supported by a particular mapping, I added a new interface XmlRpcListableHandlerMapping that provides this information, made the default handler implement it, and designed my code so that if it were not implemented by a handler in use, everything would work except the system.listMethods functionality that relies on it. I hope you will be able to integrate this code into the next version of the library; please contact me with any questions or issues. I will be attaching the patch to this issue if I can so that the problem with his previous patch will not occur. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[PATCH] Socket not closed when exception caught in listener loop
Hi,
We ran into an issue were our client application using XMLRpcClientLite
hangs if the maximum number of concurrent requests on the server is
exceeded, i.e. runners.activeCount() XmlRpc.getMaxThreads(). I found
that a socket is not closed in those circumstances and therefore the
client keeps waiting for the response. The proposed patch below would
take care of this issue.
Thanks,
Elias Zaretsky.
Index: WebServer.java
===
RCS file:
/home/cvspublic/ws-xmlrpc/src/java/org/apache/xmlrpc/WebServer.java,v
retrieving revision 1.28
diff -u -r1.28 WebServer.java
--- WebServer.java 22 Apr 2005 10:25:57 - 1.28
+++ WebServer.java 31 Oct 2005 22:48:56 -
@@ -445,9 +445,11 @@
{
while (listener != null)
{
+Socket socket = null;
+Runner runner = null;
try
{
-Socket socket = serverSocket.accept();
+socket = serverSocket.accept();
try
{
socket.setTcpNoDelay(true);
@@ -459,7 +461,7 @@
if (allowConnection(socket))
{
-Runner runner = getRunner();
+runner = getRunner();
runner.handle(socket);
}
else
@@ -487,6 +489,19 @@
+ err + ).);
err.printStackTrace();
}
+finally
+{
+if (runner == null socket != null)
+{
+try
+{
+socket.close();
+}
+catch (Throwable e)
+{
+}
+}
+}
}
}
catch (Exception exception)
Re: [PATCH]Patches and additions to make HttpClient work with Apache XML-RPC
Well you could plug your own CommonsHttpClient to handle XML-RPC posts so that's why the class is alone 2005/10/21, Jimisola Laursen [EMAIL PROTECTED]: - Original Message - From: Jochen Wiedmann [EMAIL PROTECTED] To: xmlrpc-dev@ws.apache.org Sent: Friday, October 21, 2005 9:35 PM Subject: Re: [PATCH]Patches and additions to make HttpClient work with Apache XML-RPC [EMAIL PROTECTED] wrote: I've made some additions/changes to get Commons HttpClient working correctly with Apache XML-RPC which I think can be helpful for others as well. Given the facts that the CommonsXmlRpcTransportTest works quite fine and that a real lot of people are using the CommonsXmlRpcTransport (me not included, to be honest), I wonder what your patches are good for? I think, there's some explanation required. Jochen Well, there were two of us at work that tried to get it to work but we could not see how things were connected with the DefaultXmlRpcTransportFactory. Then I realized that I don't think that DefaultXmlRpcTransportFactory can be used to get instances of CommonsXmlRpcTransport. Or? Did not think to search for a test. However, I had a look at the CommonsXmlRpcTransportTest now and it does not seem to do much more than call the constructor...? When on tests, have this projects considered to use a code (test) coverage tool? My project uses Cobertura (cobertura.sf.net) and are _very_ pleased with what it has done for us. Anyway, as I mentioned initially that I forgot to use the CVS version of CommonsXmlRpcTransport and therefore I added method for setting (read) timeout and connection timeout (setTimeout and setConnectionTimeout). However, I saw that the exact same method with the same javadocs (from Commons HttpClient) had already been added, so my changes to CommonsXmlRpcTransport probably does not have any value (or diffs other than moving instance variables together). It might be that the CommonsHttpClientXmlRpcTransportFactory is unnecessary as well, but I did not get DefaultXmlRpcTransportFactory to do the job. Can it be used? Specifically, I want a factory class for CommonsXmlRpcTransport that I can set default timeout values on the factory object so that CommonsXmlRpcTransport classes are created with these timeout values. I don't like to take up your time like this. Think a lot of these misunderstandings/uncertainties could have been eliminated if the contribution documentation was more informative and information that is out-of-date (CVS, Bugzilla, ...) was removed from home page. That said, this project is something that I have much use for and I might be able to give it some time since I am not currently working with any open-source project and would like to do so. Kind regards, Jimisola
Re: [PATCH]Patches and additions to make HttpClient work with Apache XML-RPC
- Original Message - From: Jochen Wiedmann [EMAIL PROTECTED] To: xmlrpc-dev@ws.apache.org Sent: Friday, October 21, 2005 9:35 PM Subject: Re: [PATCH]Patches and additions to make HttpClient work with Apache XML-RPC [EMAIL PROTECTED] wrote: I've made some additions/changes to get Commons HttpClient working correctly with Apache XML-RPC which I think can be helpful for others as well. Given the facts that the CommonsXmlRpcTransportTest works quite fine and that a real lot of people are using the CommonsXmlRpcTransport (me not included, to be honest), I wonder what your patches are good for? I think, there's some explanation required. Jochen Well, there were two of us at work that tried to get it to work but we could not see how things were connected with the DefaultXmlRpcTransportFactory. Then I realized that I don't think that DefaultXmlRpcTransportFactory can be used to get instances of CommonsXmlRpcTransport. Or? Did not think to search for a test. However, I had a look at the CommonsXmlRpcTransportTest now and it does not seem to do much more than call the constructor...? When on tests, have this projects considered to use a code (test) coverage tool? My project uses Cobertura (cobertura.sf.net) and are _very_ pleased with what it has done for us. Anyway, as I mentioned initially that I forgot to use the CVS version of CommonsXmlRpcTransport and therefore I added method for setting (read) timeout and connection timeout (setTimeout and setConnectionTimeout). However, I saw that the exact same method with the same javadocs (from Commons HttpClient) had already been added, so my changes to CommonsXmlRpcTransport probably does not have any value (or diffs other than moving instance variables together). It might be that the CommonsHttpClientXmlRpcTransportFactory is unnecessary as well, but I did not get DefaultXmlRpcTransportFactory to do the job. Can it be used? Specifically, I want a factory class for CommonsXmlRpcTransport that I can set default timeout values on the factory object so that CommonsXmlRpcTransport classes are created with these timeout values. I don't like to take up your time like this. Think a lot of these misunderstandings/uncertainties could have been eliminated if the contribution documentation was more informative and information that is out-of-date (CVS, Bugzilla, ...) was removed from home page. That said, this project is something that I have much use for and I might be able to give it some time since I am not currently working with any open-source project and would like to do so. Kind regards, Jimisola
[PATCH]Patches and additions to make HttpClient work with Apache XML-RPC
Hi!
I've made some additions/changes to get Commons HttpClient working correctly
with Apache XML-RPC which I think can be helpful for others as well.
1) Updated the CommonsXmlRpcTransport class (which I think should be renamed
CommonsHttpClientXmlRpcTransport)
2) Added a new factory class (CommonsHttpClientXmlRpcTransportFactory). The
factory class can have default values set for url, basic auth, (read) timeout
and connection factory class. Setting these will cause the
CommonsXmlRpcTransport created using createTransport to have these default
setting.
I've have add different versions of constructors for convenice (e.g. URL vs
host
+ port, auth vs username + password). I am not familiar on whether you like
these or not - feel free to remove some of them.
Attached file are:
- the brand new factory class CommonsHttpClientXmlRpcTransportFactory
- the updated CommonsXmlRpcTransport (I moved some instance variable
declarations so that they're all together)
- a diff -u version of CommonsXmlRpcTransport (NOTE: I just realized that I
did
not do the diff against CVS version - it's against the 2.0 version. If this is
a
problem let me know.)
Regards,
Jimisola
BACKGROUND
I could not get the XML-RPC library to work with HttpClient.
My code:
XmlRpcClient xmlRpcClient = new XmlRpcClient(new
URL(http://localhost:8080/RPC2;),
DefaultXmlRpcTransportFactory.createTransportFactory(org.apache.xmlrpc.DefaultXmlRpcTransportFactory,
new Properties()));
causes the following exception to be thrown:
Exception in thread main org.apache.xmlrpc.XmlRpcClientException: Transport
Factory constructor not found:
org.apache.xmlrpc.DefaultXmlRpcTransportFactory(java.util.Properties
properties)
at
org.apache.xmlrpc.DefaultXmlRpcTransportFactory.createTransportFactory(DefaultXmlRpcTransportFactory.java:104)
at other._TestXmlRpcTimeoutClient.main(_TestXmlRpcTimeoutClient.java:31)
Caused by: java.lang.NoSuchMethodException:
org.apache.xmlrpc.DefaultXmlRpcTransportFactory.init(java.util.Properties)
at java.lang.Class.getConstructor0(Class.java:1937)
at java.lang.Class.getConstructor(Class.java:1027)
at
org.apache.xmlrpc.DefaultXmlRpcTransportFactory.createTransportFactory(DefaultXmlRpcTransportFactory.java:82)
.. 1 more
Reason:
org.apache.xmlrpc.DefaultXmlRpcTransportFactory does not have a constructor
with
signature:
Class [] CONSTRUCTOR_SIGNATURE = new Class [] { Properties.class };
I've followed the code from beginning and as far as I can see the code can't
work with Commons HttpClient due to 1) missing constructor and 2)
CommonsXmlRpcTransport is NOT USED ANYWHERE.
1. XmlRpcClient(URL, XmlRpcTransportFactory)
2. XmlRpcTransPortFactory: SunSSLTransportFactory,
DefaultXmlRpcTransportFactory
3. DefaultXmlRpcTransportFactory: does not refer to CommonsXmlRpcTransport and
seems to be missing proper constuctor (see exception above)/**
*
*/
package org.apache.xmlrpc;
import java.net.MalformedURLException;
import java.net.URL;
import org.apache.commons.httpclient.HttpClient;
public class CommonsHttpClientXmlRpcTransportFactory implements XmlRpcTransportFactory
{
// default properties for new common http-client http transports
protected URL url;
protected String auth;
protected Integer timeout = null;
protected Integer connectionTimeout = null;
public CommonsHttpClientXmlRpcTransportFactory(String hostname, int port) throws MalformedURLException
{
this(new URL(http://; + hostname + ':' + port + /RPC2));
}
public CommonsHttpClientXmlRpcTransportFactory(String hostname, int port, String username, String password) throws MalformedURLException
{
this(new URL(http://; + hostname + ':' + port + /RPC2), username, password);
}
public CommonsHttpClientXmlRpcTransportFactory(String hostname, int port, String auth) throws MalformedURLException
{
this(new URL(http://; + hostname + ':' + port + /RPC2), auth);
}
public CommonsHttpClientXmlRpcTransportFactory(URL url)
{
this(url, null);
}
public CommonsHttpClientXmlRpcTransportFactory(URL url, String username, String password)
{
this.url = url;
this.setBasicAuthentication(username, password);
}
/**
*
* @param url
* @param auth the username:password formed string used for basic authentication
*/
public CommonsHttpClientXmlRpcTransportFactory(URL url, String auth)
{
this.url = url;
this.auth = auth;
}
public XmlRpcTransport createTransport () throws XmlRpcClientException
{
HttpClient client = new HttpClient();
CommonsXmlRpcTransport transport = new CommonsXmlRpcTransport(this.url, client);
// set basic authentication if auth (username and password) is set
if (this.auth != null)
{
transport.setBasicAuthentication(this.auth);
}
// set timeout if set
if (this.timeout != null)
{
transport.setTimeout(this.timeout.intValue());
}
// set connection timeout if set
if (this.connectionTimeout != null)
{
transport.setConnectionTimeout(this.connectionTimeout.intValue());
}
return transport;
}
Re: Fw: [PATCH] suggested patches for memory issues
Thanks Jochen, (and John for your previous comments) I take your point that this is application specific, and if older JVMs do not release interned Strings this is a strong reason not to intern by default. I will put in an alternative factory, leaving the default behaviour as it is currently (no interning) and send you the diffs when this is done. I think it might be a good idea for the implementation to write something in the logs/standard out when the factory is created, to indicate whether String intern is being used or not - since it seems an important choice for the developer to make and this might help to bring the issue into focus. Nick Extranet [EMAIL PROTECTED] - 05/10/2005 21:09 Please respond to xmlrpc-dev@ws.apache.org To:xmlrpc-dev cc: Subject:Re: Fw: [PATCH] suggested patches for memory issues [EMAIL PROTECTED] wrote: Our application will run with approximately 1/5th of the previous memory with the interns in (which is the difference between total success of the project and total failure) This indicates, that your application has a lot of hits in the map of intern'd strings. In other words, intern() is good for you. (Which I wasn't discussing.) Other applications will not have such a lot of hits. In other words, they will increase the internal map without any reason: The achieved effect may be quite the converse of the desired. Interning is an application specific optimization. In general, it pays to leave the JVM doing its work without enforcing certain optimizations. I do not believe, that a general purpose library like XML-RPC should do things like that. That is my personal experience, which may not be yours, of course. However, note that Johns previous posting has already suggested that at least some JVM's may have a totally different behaviour than what you would expect. Besides, if interning would always help, then it could be made a JVM option. I am still convinced that the defaults should be left as they are. However, your numbers are clearly indicating that there are good reasons for creating a new option. Jochen This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. ** BNP Paribas Private Bank London Branch is authorised by CECEI AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Securities Services London Branch is authorised by CECEI AMF and is regulated by the Financial Services Authority for the conduct of its investment business in the United Kingdom. BNP Paribas Fund Services UK Limited is authorised and regulated by the Financial Services Authority.
Re: Fw: [PATCH] suggested patches for memory issues
[EMAIL PROTECTED] wrote: Our application will run with approximately 1/5th of the previous memory with the interns in (which is the difference between total success of the project and total failure) This indicates, that your application has a lot of hits in the map of intern'd strings. In other words, intern() is good for you. (Which I wasn't discussing.) Other applications will not have such a lot of hits. In other words, they will increase the internal map without any reason: The achieved effect may be quite the converse of the desired. Interning is an application specific optimization. In general, it pays to leave the JVM doing its work without enforcing certain optimizations. I do not believe, that a general purpose library like XML-RPC should do things like that. That is my personal experience, which may not be yours, of course. However, note that Johns previous posting has already suggested that at least some JVM's may have a totally different behaviour than what you would expect. Besides, if interning would always help, then it could be made a JVM option. I am still convinced that the defaults should be left as they are. However, your numbers are clearly indicating that there are good reasons for creating a new option. Jochen
Re: [PATCH] suggested patches for memory issues
Thanks for the report Nick.
Could you use the diff -Nru so we could see easily the update ?
BTW, happy to see someone using ASF XML-RPC, working in the same
professional area than me :)
Regards
2005/9/27, [EMAIL PROTECTED] [EMAIL PROTECTED]:
Hi there at the XML RPC project.
We have been using XML-RPC heavily in our current project. Thanks for your
hard work on this.
We have made a couple of modifications which we would like to submit for
your consideration - which correct a couple of memory issues we were
having:
Fix to allow last query results to be garbage collected.
---
The class XmlRpcClientResponseProcessor currently fails to set the field
'result' to null at the end of the decodeResponse method.
The effect of this is that the results of the last query are not garbage
collected (until another query takes place) - and this is quite visible in
our client application.
We have fixed this by adding the finally block in the method - as below:
XmlRpcClientResponseProcessor class Line 59 - added finally block to set
result field to null
/**
* Decode an XML-RPC response from the specified InputStream.
*
* @param is The stream from which to read the response.
* @return The response, which will be a XmlRpcException if an
* error occured.
* @exception XmlRpcClientException
*/
public Object decodeResponse(InputStream is)
throws XmlRpcClientException
{
result = null;
fault = false;
try
{
parse(is);
if (fault)
{
return decodeException(result);
}
else
{
return result;
}
}
catch (Exception x)
{
throw new XmlRpcClientException(Error decoding XML-RPC
response, x);
}
finally
{
result = null;
}
}
Fix to allow Strings to be interned
We had a memory problem caused by Strings in our client application not
being interned, and made some changes so that the XML RPC processor
interned Strings (both values and the keys in Maps). This reduced our
client memory footprint by a factor of 10 from around 500 MB to 50MB in
heavy usage
To do this we changed:
DefaultTypeFactory class Line 105 - modified the createString method to
intern the String created
public Object createString(String cdata)
{
return cdata.intern();
}
XmlRpc class Line 607 in startElement method - uncomment the line to enable
setType (otherwise the DefaultTypeFactory above is not used to generate the
String instances)
currentValue.setType (STRING);
XmlRpc class Line 758 - characterData method, add intern() to enable keys
used in maps to be pooled
case STRUCT:
// this is the name to use for the next member of this struct
nextMemberName = cdata.intern();
Thanks again,
Nick Ebbutt
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
**
BNP Paribas Private Bank London Branch is authorised
by CECEI AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Securities Services London Branch is authorised
by CECEI AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Fund Services UK Limited is authorised and
regulated by the Financial Services Authority.
[PATCH] suggested patches for memory issues
Hi there at the XML RPC project.
We have been using XML-RPC heavily in our current project. Thanks for your
hard work on this.
We have made a couple of modifications which we would like to submit for
your consideration - which correct a couple of memory issues we were
having:
Fix to allow last query results to be garbage collected.
---
The class XmlRpcClientResponseProcessor currently fails to set the field
'result' to null at the end of the decodeResponse method.
The effect of this is that the results of the last query are not garbage
collected (until another query takes place) - and this is quite visible in
our client application.
We have fixed this by adding the finally block in the method - as below:
XmlRpcClientResponseProcessor class Line 59 - added finally block to set
result field to null
/**
* Decode an XML-RPC response from the specified InputStream.
*
* @param is The stream from which to read the response.
* @return The response, which will be a XmlRpcException if an
* error occured.
* @exception XmlRpcClientException
*/
public Object decodeResponse(InputStream is)
throws XmlRpcClientException
{
result = null;
fault = false;
try
{
parse(is);
if (fault)
{
return decodeException(result);
}
else
{
return result;
}
}
catch (Exception x)
{
throw new XmlRpcClientException(Error decoding XML-RPC
response, x);
}
finally
{
result = null;
}
}
Fix to allow Strings to be interned
We had a memory problem caused by Strings in our client application not
being interned, and made some changes so that the XML RPC processor
interned Strings (both values and the keys in Maps). This reduced our
client memory footprint by a factor of 10 from around 500 MB to 50MB in
heavy usage
To do this we changed:
DefaultTypeFactory class Line 105 - modified the createString method to
intern the String created
public Object createString(String cdata)
{
return cdata.intern();
}
XmlRpc class Line 607 in startElement method - uncomment the line to enable
setType (otherwise the DefaultTypeFactory above is not used to generate the
String instances)
currentValue.setType (STRING);
XmlRpc class Line 758 - characterData method, add intern() to enable keys
used in maps to be pooled
case STRUCT:
// this is the name to use for the next member of this struct
nextMemberName = cdata.intern();
Thanks again,
Nick Ebbutt
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
**
BNP Paribas Private Bank London Branch is authorised
by CECEI AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Securities Services London Branch is authorised
by CECEI AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Fund Services UK Limited is authorised and
regulated by the Financial Services Authority.
Re: [PATCH] characters invalid for an encoding
On Fri, 2005-05-06 at 14:59 +0100, John Wilson wrote:
On 6 May 2005, at 12:03, Jochen Wiedmann wrote:
...
For maximum interoperability I would suggest we use UTF-8 but use
character references for all values 0X7F. This means that even
if the
other end gets the encoding wrong it will still almost certainly
understand the characters. If the other end does not understand
character encodings it will be very easy to see what the problem is
(which is not quite so easy to do if it mistakes UTF-8 for ISO8859-1,
for example)
That is, as far as I can say, what Daniels proposed patch does.
Yes It would appear to do this. However it also seems to emit invalid
XML code points as character references (e.g. the NULL character
would be emitted as #x0;).
That's right -- it was intentional, as I was unaware of this
restriction, and figured I'd start with the parts it seemed that
everyone agreed on. :-)
I do not believe that the XML spec allows
this. I believe that these code points cannot appear in a well formed
document in any form. The intent is to allow the consuming
application to be 100% sure it never sees these characters.
I did a some looking around, and the closest thing I could find
supporting that is an email by Tim Bray:
http://lists.xml.org/archives/xml-dev/199804/msg00502.html
I also found some conformance testing materials against a really old XML
parser from Sun:
http://www.xml.com/1999/09/conformance/reports/report-sun-val.html
I took a look through the spec, but nothing stood out. John, are there
any particular portions of the spec that I should be looking at in
particular? The section on valid characters is really clear that the
majority of control characters can't occur, but I didn't see any
discussion as to why replacing them with character references isn't a
good enough escaping mechanism. Not trying to be obstructionist -- just
trying to understand.
I've committed patches to CVS HEAD and XMLRPC_1_2_BRANCH implementing
everything we've discussed (including test cases), _except_ the blocking
of these suspect control characters. Attached is a patch which could be
applied to CVS HEAD to block such characters, but if we end up going
that route, it's probably time to optimize the changes I've made
recently to XmlWriter.
Index: src/java/org/apache/xmlrpc/XmlWriter.java
===
RCS file: /home/cvs/ws-xmlrpc/src/java/org/apache/xmlrpc/XmlWriter.java,v
retrieving revision 1.15
diff -u -r1.15 XmlWriter.java
--- src/java/org/apache/xmlrpc/XmlWriter.java 16 May 2005 22:39:27 - 1.15
+++ src/java/org/apache/xmlrpc/XmlWriter.java 16 May 2005 22:50:50 -
@@ -429,6 +429,13 @@
// outside of the valid range for ASCII, too.
if (c 0x7f || !isValidXMLChar(c))
{
+if (isDisallowedControlChar(c))
+{
+throw new XmlRpcException
+(0, Invalid XML character corresponding to +
+ code point + String.valueOf((int) c));
+}
+
// Replace the code point with a character reference.
writeCharacterReference(c);
}
@@ -469,6 +476,31 @@
}
}
+/**
+ * John Wilson indicates that some characters simply aren't
+ * allowed in XML documents, even as character references.
+ *
+ * @return Whether the specified character is a control character
+ * which is disallowed in XML.
+ */
+private static final boolean isDisallowedControlChar(char c)
+{
+if (c 0x20)
+{
+switch (c)
+{
+case 0x9:
+case 0xa: // line feed, '\n'
+case 0xd: // carriage return, '\r'
+return false;
+
+default:
+return true;
+}
+}
+return false;
+}
+
protected static void setTypeDecoder(TypeDecoder newTypeDecoder)
{
typeDecoder = newTypeDecoder;
Re: [PATCH] characters invalid for an encoding
On 6 May 2005, at 12:03, Jochen Wiedmann wrote: For version 3, I have code ready that checks the presence of Java 1.4. It that is available, an instance of Charset is being queried. Yes that works fine - I'm too used to living with the need to support J2ME. I forget the nice things in 1.4 :) For maximum interoperability I would suggest we use UTF-8 but use character references for all values 0X7F. This means that even if the other end gets the encoding wrong it will still almost certainly understand the characters. If the other end does not understand character encodings it will be very easy to see what the problem is (which is not quite so easy to do if it mistakes UTF-8 for ISO8859-1, for example) That is, as far as I can say, what Daniels proposed patch does. Yes It would appear to do this. However it also seems to emit invalid XML code points as character references (e.g. the NULL character would be emitted as #x0;). I do not believe that the XML spec allows this. I believe that these code points cannot appear in a well formed document in any form. The intent is to allow the consuming application to be 100% sure it never sees these characters. John Wilson The Wilson Partnership http://www.wilson.co.uk
Re: [PATCH] characters invalid for an encoding
On Thu, 2005-05-05 at 02:35 +0200, Jochen Wiedmann wrote:
Daniel Rall wrote:
...
What does invalid as un-encoded XML mean? Not being within the
encodings character set?
I was referring to characters which had not been entity-encoded using
references like lt; or #0x;.
If so, the range 0x20 to 0xff is quite arbitrarily and not even valid in
all cases. For example, it fails for US-ASCII encoding. In other
words, to me this wasn't good.
This change was only intended to catch characters invalid in XML, which
it did an incomplete job of.
...
- Choose UTF-8 as the encoding; that means, that only very few
characters ('', for example) has to be escaped.
Ideally speaking, this option also strikes me as the cleanest. Sadly,
the reality is that there are a lot of old XML-RPC clients and servers
out there in production, and that we could only offer this behavior as a
non-default configuration toggle.
- Choose US-ASCII as the encoding. In other words, escape everything
beyond 0x7f.
John Wilson also made this suggestion. Given the very real inter-op
concerns we have to live with, I propose that this be the default
behavior.
- Invent a new interface and let the user decide, for example:
public class XmlRpcEncoder {
String getEncoding();
boolean isEscaped(char pChar);
}
Not to over-engineer things, I also envisioned this type of solution to
implement the UTF-8 toggle discussed above.
Re: [PATCH] characters invalid for an encoding
On Thu, 2005-05-05 at 15:24 +0100, John Wilson wrote:
I'm not sure I follow this either :)
Currently we emit an XML declaration which says we are using
ISO8859-1 encoding.
The declaration generated depends upon the encoding in use by XmlWriter,
no?
write(PROLOG_START);
write(canonicalizeEncoding(enc));
write(PROLOG_END);
Unicode code points in the range 0X00 to 0XFF
have the same value as the ISO8859-1 character values. If we wish to
send Unicode code points with values 0XFF then we have to emit
character references (e.g. x1FF;)
If we were to change the encoding to UTF-8 or UTF-16 then we would
never have to emit character references (though we still could if we
wanted to).
Like you say below, we'd still have to emit character references for
Unicode code points not allowed in XML documents, yes?
The XML 1.0 spec forbids some Unicode code points from appearing in a
well formed XML document (only these code points are allowed: #x9 |
#xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] -
see section 2.2 of the spec.). Note that USASCII control characters
other than HT, CR and NL are not allowed. Using a character reference
doesn't make any difference a#x0;/a is not a well formed XML
document and should be rejected by an XML parser (MinML used not to
complain about this - later versions do).
What range are these control characters in (e.g. 0x20)?
There is another little wrinkle with CR and LF. An XML parser is
required to normalise line endings (see section 2.11 of the spec).
This normalisation involves replacing CR NL or CR with NL. This
normalisation does not occur if the CR is represented using a
character reference.
So a correct XML writer should do the following:
1/ refuse to write characters with Unicode code points which are not
allowed in an XML document.
Do you suggest throwing an exception here, or writing a '?' character?
2/ replace characters with a Unicode code point which is not allowed
in the encoding being used with the appropriate character reference.
For any random encoding, anyone know a good way of determining whether
such a character is representable by said encoding?
3/ replace , and with either the pre defined entities (lt; etc)
or with a character reference.
We're already replacing them with pref-defined entities, so we're in
good shape here.
4/ replace all CR characters with a character reference.
We do this to keep them from getting normalized by the XML parser, I
take it? Previously, we'd write them literally.
If we wanted to have the greatest possible chance of interoperating
we should emit no XML encoding declaration and replace code points
with values 0X7F with character references.
I agree with the part about replacing code points with values 0x7f
with character references (see exchange with Jochen).
Can non-ASCII encodings be determined by the parser using the BOM, or
some such heuristic? Would we write all non-ASCII encoding as UTF-8?
I'm attaching a patch as a discussion piece which implements some of the
discussion from this thread.
Index: XmlWriter.java
===
RCS file: /home/cvs/ws-xmlrpc/src/java/org/apache/xmlrpc/XmlWriter.java,v
retrieving revision 1.13
diff -u -u -r1.13 XmlWriter.java
--- XmlWriter.java 2 May 2005 04:22:21 - 1.13
+++ XmlWriter.java 5 May 2005 21:36:38 -
@@ -40,6 +40,8 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Hannes Wallnoefer/a
* @author Daniel L. Rall
+ * @see a href=http://www.xml.com/axml/testaxml.htm;Tim Bray's
+ * Annotated XML Spec/a
*/
class XmlWriter extends OutputStreamWriter
{
@@ -246,6 +248,17 @@
}
/**
+ * Writes characters like '\r' (0xd) as amp;#13;.
+ */
+private void writeCharacterReference(char c)
+throws IOException
+{
+write(#);
+write(String.valueOf((int) c));
+write(';');
+}
+
+/**
*
* @param elem
* @throws IOException
@@ -303,10 +316,13 @@
switch (c)
{
case '\t':
-case '\r':
case '\n':
write(c);
break;
+case '\r':
+// Avoid normalization of CR to LF.
+writeCharacterReference(c);
+break;
case '':
write(LESS_THAN_ENTITY);
break;
@@ -317,38 +333,18 @@
write(AMPERSAND_ENTITY);
break;
default:
-if (c 0x20 || c 0x7f)
+// Though the XML spec requires XML parsers to support
+// Unicode, not all such code points are valid in XML
+// documents. Additionally, previous to 2003-06-30
+// the XML-RPC spec only allowed ASCII data (in
+// string elements). For interoperability with
+// clients rigidly
Re: [PATCH] characters invalid for an encoding
Daniel Rall wrote:
On 2002/08/19, CVS rev 1.3 of XmlWriter introduced code to entity encode
characters in the range 0x20 to 0xff, characters which are invalid as
un-encoded _XML_. And so it was Good.
Sorry for asking, but I tend to become more and more confused. :-)
What does invalid as un-encoded XML mean? Not being within the
encodings character set?
If so, the range 0x20 to 0xff is quite arbitrarily and not even valid in
all cases. For example, it fails for US-ASCII encoding. In other
words, to me this wasn't good.
With the restriction on ASCII-only string payloads removed, do we want
to go back to the days of CVS rev 1.3, where all characters which are
not valid _XML_ are entity encoded, and no special handling is enforced
based on the XmlWriter's encoding?
Besides the fact, that I do not understand, what has actually been
restricted (lexical representation or actual character set) and that the
latter would make XML-RPC pretty useless to most of us: The restriction
is away.
So we have, IMO, the following options:
- Choose UTF-8 as the encoding; that means, that only very few
characters ('', for example) has to be escaped.
- Choose US-ASCII as the encoding. In other words, escape everything
beyond 0x7f.
- Invent a new interface and let the user decide, for example:
public class XmlRpcEncoder {
String getEncoding();
boolean isEscaped(char pChar);
}
I do personally favour the first option very clearly.
Jochen
Re: [PATCH] characters invalid for an encoding
On Mon, 2005-05-02 at 17:43 -0700, Steve Quint wrote: At 8:50 PM -0700 5/1/05, Daniel L. Rall wrote: Ignoring the encoding=... XML header, that would indeed be valid XML. However, when the XML is subsequently processed, the entity-encoded value will transformed into ASCII. Since there is no equivalent 7 bit ASCII character which fits within that range (e.g. 0x7f is ASCII 127), a parse error will be generated. I believe it is incorrect for XMLWriter to make any assumptions about encodings, especially since the encoding is passed in the constructor. Hi Steve, can you elaborate on this? Both the XML RFCs and certain encodings dictate what constitutes valid content, and how content must be represented. For instance, certain multi-byte characters simply aren't representable in 7 bit encoding like ASCII -- the only way to deliver'em through an ASCII encoding is to use another encoding which can be represented in ASCII (e.g. base-64). If I create an instance of XMLWriter that I expect to support a binary encoding that I passed in the constructor, I shouldn't have to worry about an encoding related error later on. Encoding related errors should probably happen at the time I specify an encoding. How do you recommend that be done, given the content to write isn't available until the writeObject() method is called? It seems to me that you don't know whether the content is representable in your specified encoding until you get the content... This behavior seems reasonably consistent with the JDK, which declares that a Writer can throw an IOException (which UnsupportedEncodingException is an instance of). http://java.sun.com/j2se/1.4.2/docs/api/java/io/Writer.html#write(java.lang.String) If this is truly the behavior you wish to enforce, and I see no reason for it, perhaps the Constructor should throw an UnsupportedEncodingException if the encoding is neither UTF-8 nor UTF-16. I don't follow you. The XML-RPC spec itself used to dictate that the XML payload must be ASCII. That changed only recently. Thanks for the review! - Dan
