xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aev...@redwood.nl>
Subject Alternative type mappings for primitive types.
Date Thu, 08 Aug 2002 09:24:24 GMT

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 Evers.
Systems Engineer - Redwood Software

View raw message