Daniel Rall wrote:
Why is that a problem? I was under the impression that this patch was
to make XML-RPC work across different versions of Commons Codec. Do
these Codec methods have different implementations with wildly different
semantics?
The problem is that the methods have different signat
Daniel Rall wrote:
Jochen Wiedmann wrote:
Daniel L. Rall wrote:
-return base64Codec.decode(cdata.getBytes());
+return base64Codec.decode((Object) cdata.getBytes());
This cast looks unnecessary. What's the thinking here?
No, it's required, because the compiler would pick t
Jochen Wiedmann wrote:
Daniel L. Rall wrote:
-return base64Codec.decode(cdata.getBytes());
+return base64Codec.decode((Object) cdata.getBytes());
This cast looks unnecessary. What's the thinking here?
No, it's required, because the compiler would pick the old method
otherw
Daniel L. Rall wrote:
-return base64Codec.decode(cdata.getBytes());
+return base64Codec.decode((Object) cdata.getBytes());
This cast looks unnecessary. What's the thinking here?
No, it's required, because the compiler would pick the old method otherwise.
Jochen Wiedmann wrote:
the following patch makes XmlRpc running with codec 1.2.
Comments inline. (And I'm all for "letting it suck" -- +1 on a little less
elegance over interoperability any day.)
Index: DefaultTypeFactory.java
===
R
Hi,
the following patch makes XmlRpc running with codec 1.2.
Jochen
Index: DefaultTypeFactory.java
===
RCS file: /home/cvspublic/ws-xmlrpc/src/java/org/apache/xmlrpc/DefaultTypeFactory.java,v
retrieving revision 1.3
diff -u -r1.3
