xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: Alternative type mappings for primitive types.
Date Thu, 08 Aug 2002 18:44:24 GMT
<aevers@redwood.nl> writes:

> I have been using a modified version of the Apache XML-RPC implementation
> as part of a distributed system that uses XML-RPC for its inter-system
> communication. As part of this project we needed to modify the type
> mapping used by XML-RPC to handle very large numbers (ie. arbitrary
> precision a'la java.math.Big{Decimal,Number}).
> I have made and tested a patch against release version 1.1, however, this
> means that we have to maintain the patch, and keep up with changes and
> updates from the maintainers. We would prefer to contribute a patch
> to add this capability to the official version.
> The current modifications only change the behaviour of integers,
> mapping them to java.math.BigInteger instead of Integer. I would like
> to extend this to allowing all the primitive XML-RPC types to be
> mapped to arbitrary objects.
> The changes involve creating new interface TypeFactory with methods to
> construct each of the primitive types. A new class TypeFactoryBasethat implements the
default behaviour for TypeFactory, ie. the current
> behaviour in XmlRpc.Value.characterData(). These handle the arbitrary
> type mapping.
> Changes to the existing classes involve adding new constructors to
> the XmlRpcServer and XmlRpc classes that take an extra TypeFactory
> argument. The current constructors should be changed to use a static
> defaultTypeFactory member. The TypeFactory instance is passed
> from XmlRpcServer to XmlRpc via the constructor call in
> XmlRpcServer.Worker. The XmlRpc.Value.characterData is converted
> to call the TypeFactory interface methods.
> Finally, WebServer and SecureWebServer get a new constructor
> that takes an XmlRpcServer argument. The current constructors call
> this constructor with new XmlRpcServer() as the final argument.
> I have spoken to my employer and they (and I) are happy to provide
> this patch and the associated legal wranglings to give ASF control
> over changes/copyright/whatever the need may be.
> I look forward to your response.

Andrew, sounds interesting.  Maintaing custom patches is never fun;
let's have a look at it.


JUnit tests for the existing interfaces and for any new code would be
VERY helpful as well.

Daniel Rall <dlr@finemaltcoding.com>

View raw message