Recent changes to bugs

#30 JSON Serializer produces invalid JSON

Lorenzo Masetti — Tue, 19 Jul 2016 13:59:24 -0000

hi Gregor, seems you forgot about this issue :)
Actually XmlRpcJsonSerializer.java is working fine so you can include it in the next release.

#30 JSON Serializer produces invalid JSON

Lorenzo Masetti — Mon, 04 Jan 2016 09:07:25 -0000

hello, happy new year
Any plan to include this fix in the next release?

#30 JSON Serializer produces invalid JSON

Lorenzo Masetti — Thu, 17 Dec 2015 14:12:48 -0000

Hello again Gregor,
just to tell you that I tested the modified version in my project and it works fine so you can include it in the next release if you want,

#30 JSON Serializer produces invalid JSON

Lorenzo Masetti — Wed, 16 Dec 2015 15:52:14 -0000

Hi Gregor.
Thanks for the fast answer. I guess it is a bit complext to give access rights to the repository but I attach the patched version of the serializer (basically i just merged the code that i was writing in the subclass). It is not tested (I did not even try to complie) but it should work if i did not do anything wrong with the copy paste

#30 JSON Serializer produces invalid JSON

Greger Olsson — Wed, 16 Dec 2015 15:28:03 -0000

On another topic; perhaps this is a good time to move the repository to GitHub? That would make it a lot easier for people to contribute to the library than with the bulky SF.

#30 JSON Serializer produces invalid JSON

Greger Olsson — Wed, 16 Dec 2015 15:25:28 -0000

Hi Lorentzo,

Thanks for your bug report. The XmlRpcJsonSerializer is an old thing (2006, maybe older) that didn't follow any particular RPC-specification like JSON-RPC. So it definitely needs some fixes if people are still using it -- I also saw that it serializes Dates wrong.

I'm a bit swamped with a few projects right now, but If you'd like to help I could give you commit access to the repository?

JSON Serializer produces invalid JSON

Lorenzo Masetti — Wed, 16 Dec 2015 12:51:01 -0000

The XmlRpcJsonSerializer is not producing valid json strings (it uses single quotes instead of double quotes), Moreover in the JSON-rpc standard the result should be inside a property called result.
I attach my class extending the functionality of XmlRpcJsonSerializer to fix these issues but I would reccomend to merge these changes inside XmlRpcJsonSerializer

XmlRpcServlet is not serializable

fkal — Fri, 24 Aug 2012 12:00:35 -0000

XmlRpcServlet is not serializable, since it has a non-transient field ("server") which is not serializable.
I think the field "server" should be made transient, it will be re-set in the class' init method.

An attempted seriliaziation of a subclass of XmlRpcServlet, leads to the following exception (if its _init_ method was called _before_!):
java.io.NotSerializableException: redstone.xmlrpc.XmlRpcServer
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)

XmlRpcServlet's init() method should call super.init()

fkal — Fri, 24 Aug 2012 08:20:49 -0000

XmlRpcServlet overrides the method "public void init( ServletConfig config ) throws ServletException" of javax.servlet.GenericServlet, but does not call super.init(). This will lead to multiple methods of GenericServlet, which depend on the ServletConfig being set in the config field, returning null, e.g. getServletConfig and getServletContext.

I went through the implementation of GenericServlet and HttpServlet and it seems like those methods are not used, but extendsion of XmlRpcServlet may do, so it makes sense to call super in my opinion.

Incorrect content-length calculation in XmlRpcServlet

Anonymous — Thu, 21 Jul 2011 22:09:50 -0000

When cacluating the content length for XMLRPC replies, the current implementation of XMLRPC servelet just serializes the response into a string and gets its length. This gives the number of characters in the string and not the number of encoded bytes. There is a difference between the two when dealing with characters with multi byte encodings (e.g. kanji characters when encoded in UTF-8), and this results in truncated responses from the XmlRpcServelet when sending responses with such characters.

Patch for fix attached