If I attempt to utilize any ordered structure (LinkedHashMap, TreeMap, SortedSet, etc.) as a return value for a server invocation, the resulting values on the client side come back as a regular HashMap which means the ordering of values is usually corrupted. While I see how I am able to create a custom serializer on the server side, I see no means of creating a custom deserializer on the client side so that I can parse the serialized XML in the same order it is received.
Generally speaking, I find this to be a bug. The deserialized content should be returned in the same order it was serialized and not reordered at the client side simply because the deserializer uses a HashMap rather than a LinkedHashMap which should provide predictable FIFO ordering.
Due to how the XML-RPC protocol is designed, the actual values that can be sent over the wire are limited. The main goal of the protocol is interoperability between programming languages and consequently the set of supported data types is kept short.
So there is no notion of sorted sets/hashes/maps in XML-RPC, although the serializers in this library know how to convert all types of Java maps to a regular XML-RPC struct to be consumed by any XML-RPC implementation. Any form of ordering in the map is innevetably lost in the translation which is an inherent limitation in the protocol, not in the library.
Remember that a service must be consumable by any language that supports the protocol, and ordered maps/hashes may not be supported by all languages.
I'm aware of the XML-RPC specification. But ultimately the underlying data transferred on the wire is XML and XML definitely has a concept of ordering in the serialized structure. I see no reason why the API should explicitely be UNordering the data before we send it. Rather, let the client side worry about whether they have structures capable of maintaining the sort order. If not, it becomes unsorted at the client side. If so, we've maintained the sort. With the current implementation, you're basically PREVENTING a client/server environment from ever sending ordered data even if both client and server do support it.
BTW, I was able to get the functionality I needed very easily by having XmlRpcStruct inherit from LinkedHashMap instead of HashMap. Once that is done, the XML structs have predicatable ordereing at least when they are sent from the server. I have yet to find any issue with this modification other than the overhead from using a LinkedHashMap.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.