You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by ae...@redwood.nl on 2002/08/08 11:24:24 UTC
Alternative type mappings for primitive types.
Hello,
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
http://www.redwood.com/
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>
>
>>As far as I can tell this dependency would be introduced anywhere we
>>want to automatically discover an implementation class for an
>>interface. We could break it off into an AutoDiscoverFactory class
>>that sits in another package. The reason I bring it up is that
>>automatic discovery of classes provides a clean way to provide a
>>default implementation while providing flexibility to the end user for
>>specifying alternate implementations for an interface.
>>
>>
>
>Definitely useful, but IMHO not worth 62k on the applet side.
>
>
You're probably right. Perhaps we should revisit this when Andrew and
my code changes settle down. We have started discussing breaking things
down into more modular packages with dependencies going only up the tree
(org.apache.xmlrpc.XXX can depend on whatever but org.apache.xmlrpc can
not depend on anything downstream).
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>
>
>>As far as I can tell this dependency would be introduced anywhere we
>>want to automatically discover an implementation class for an
>>interface. We could break it off into an AutoDiscoverFactory class
>>that sits in another package. The reason I bring it up is that
>>automatic discovery of classes provides a clean way to provide a
>>default implementation while providing flexibility to the end user for
>>specifying alternate implementations for an interface.
>>
>>
>
>Definitely useful, but IMHO not worth 62k on the applet side.
>
>
You're probably right. Perhaps we should revisit this when Andrew and
my code changes settle down. We have started discussing breaking things
down into more modular packages with dependencies going only up the tree
(org.apache.xmlrpc.XXX can depend on whatever but org.apache.xmlrpc can
not depend on anything downstream).
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Ryan Hoegg <rh...@isisnetworks.net> writes:
> >
> >>You might be interested in the Commons Discovery project, which
> >>provides a standard (?) way to find implementations of a given
> >>interface. I am going to look into this as a possibility for
> >>streamlining the new XmlRpcTransport interface code I am working on
> >>with Andrew Evers.
> >>
> >>
> >>Project: http://jakarta.apache.org/commons/discovery.html
> >>
> >>Good place to get a quick and dirty idea of what this stuff does:
> >>http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
>
> >Would this dependency only be necessary on the server side, or would
> >it be a requirement on the client side as well?
>
> You have to forgive me, I spend most of my time programming larger
> applications where footprint isn't as much of an issue as with
> libraries such as this :)
Tell me about it. SourceCast is freakin' HUGE -- currently 924 MB for
a built source tree. Perhaps that gives you guys an indication of
where all my time is going. ;)
> The JAR for 0.1 is 62K.
IMHO, every little bit matters on the applet side. Last time we
polled, it seemed we had enough users that it was worth still
supporting that use case.
> As far as I can tell this dependency would be introduced anywhere we
> want to automatically discover an implementation class for an
> interface. We could break it off into an AutoDiscoverFactory class
> that sits in another package. The reason I bring it up is that
> automatic discovery of classes provides a clean way to provide a
> default implementation while providing flexibility to the end user for
> specifying alternate implementations for an interface.
Definitely useful, but IMHO not worth 62k on the applet side.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Ryan Hoegg <rh...@isisnetworks.net> writes:
> >
> >>You might be interested in the Commons Discovery project, which
> >>provides a standard (?) way to find implementations of a given
> >>interface. I am going to look into this as a possibility for
> >>streamlining the new XmlRpcTransport interface code I am working on
> >>with Andrew Evers.
> >>
> >>
> >>Project: http://jakarta.apache.org/commons/discovery.html
> >>
> >>Good place to get a quick and dirty idea of what this stuff does:
> >>http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
>
> >Would this dependency only be necessary on the server side, or would
> >it be a requirement on the client side as well?
>
> You have to forgive me, I spend most of my time programming larger
> applications where footprint isn't as much of an issue as with
> libraries such as this :)
Tell me about it. SourceCast is freakin' HUGE -- currently 924 MB for
a built source tree. Perhaps that gives you guys an indication of
where all my time is going. ;)
> The JAR for 0.1 is 62K.
IMHO, every little bit matters on the applet side. Last time we
polled, it seemed we had enough users that it was worth still
supporting that use case.
> As far as I can tell this dependency would be introduced anywhere we
> want to automatically discover an implementation class for an
> interface. We could break it off into an AutoDiscoverFactory class
> that sits in another package. The reason I bring it up is that
> automatic discovery of classes provides a clean way to provide a
> default implementation while providing flexibility to the end user for
> specifying alternate implementations for an interface.
Definitely useful, but IMHO not worth 62k on the applet side.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>>Daniel Rall wrote:
>>
>>>"Andrew Evers" <ae...@redwood.nl> writes:
>>>
>>>>>>From an overall embedding perspective it would be nice to specify
>>>>a property hash to a number of the constructors that could be
>>>>used to specify alternative classes for not only the type factory,
>>>>but also the request or response processor, or the worker. This
>>>>would provide more graceful construction as more optional features
>>>>are added.
>>>>
>>>>The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
>>>>API's use similar concepts.
>>>>
>>>>
>>>>
>>>Interested in patching?
>>>
>>>
>>>
>>You might be interested in the Commons Discovery project, which
>>provides a standard (?) way to find implementations of a given
>>interface. I am going to look into this as a possibility for
>>streamlining the new XmlRpcTransport interface code I am working on
>>with Andrew Evers.
>>
>>
>>Project: http://jakarta.apache.org/commons/discovery.html
>>
>>Good place to get a quick and dirty idea of what this stuff does:
>>http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
>>
>>
>
>Would this dependency only be necessary on the server side, or would
>it be a requirement on the client side as well?
>
>
You have to forgive me, I spend most of my time programming larger
applications where footprint isn't as much of an issue as with libraries
such as this :) The JAR for 0.1 is 62K.
As far as I can tell this dependency would be introduced anywhere we
want to automatically discover an implementation class for an interface.
We could break it off into an AutoDiscoverFactory class that sits in
another package. The reason I bring it up is that automatic discovery
of classes provides a clean way to provide a default implementation
while providing flexibility to the end user for specifying alternate
implementations for an interface.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Ryan Hoegg <rh...@isisnetworks.net> writes:
>
>>Daniel Rall wrote:
>>
>>>"Andrew Evers" <ae...@redwood.nl> writes:
>>>
>>>>>From an overall embedding perspective it would be nice to specify
>>>>a property hash to a number of the constructors that could be
>>>>used to specify alternative classes for not only the type factory,
>>>>but also the request or response processor, or the worker. This
>>>>would provide more graceful construction as more optional features
>>>>are added.
>>>>
>>>>The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
>>>>API's use similar concepts.
>>>>
>>>>
>>>>
>>>Interested in patching?
>>>
>>>
>>>
>>You might be interested in the Commons Discovery project, which
>>provides a standard (?) way to find implementations of a given
>>interface. I am going to look into this as a possibility for
>>streamlining the new XmlRpcTransport interface code I am working on
>>with Andrew Evers.
>>
>>
>>Project: http://jakarta.apache.org/commons/discovery.html
>>
>>Good place to get a quick and dirty idea of what this stuff does:
>>http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
>>
>>
>
>Would this dependency only be necessary on the server side, or would
>it be a requirement on the client side as well?
>
>
You have to forgive me, I spend most of my time programming larger
applications where footprint isn't as much of an issue as with libraries
such as this :) The JAR for 0.1 is 62K.
As far as I can tell this dependency would be introduced anywhere we
want to automatically discover an implementation class for an interface.
We could break it off into an AutoDiscoverFactory class that sits in
another package. The reason I bring it up is that automatic discovery
of classes provides a clean way to provide a default implementation
while providing flexibility to the end user for specifying alternate
implementations for an interface.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >"Andrew Evers" <ae...@redwood.nl> writes:
> >
> >
>
> >>>From an overall embedding perspective it would be nice to specify
> >>a property hash to a number of the constructors that could be
> >>used to specify alternative classes for not only the type factory,
> >>but also the request or response processor, or the worker. This
> >>would provide more graceful construction as more optional features
> >>are added.
> >>
> >>The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
> >>API's use similar concepts.
> >>
>
> >
> >Interested in patching?
> >
>
>
> You might be interested in the Commons Discovery project, which
> provides a standard (?) way to find implementations of a given
> interface. I am going to look into this as a possibility for
> streamlining the new XmlRpcTransport interface code I am working on
> with Andrew Evers.
>
>
> Project: http://jakarta.apache.org/commons/discovery.html
>
> Good place to get a quick and dirty idea of what this stuff does:
> http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
Would this dependency only be necessary on the server side, or would
it be a requirement on the client side as well?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >"Andrew Evers" <ae...@redwood.nl> writes:
> >
> >
>
> >>>From an overall embedding perspective it would be nice to specify
> >>a property hash to a number of the constructors that could be
> >>used to specify alternative classes for not only the type factory,
> >>but also the request or response processor, or the worker. This
> >>would provide more graceful construction as more optional features
> >>are added.
> >>
> >>The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
> >>API's use similar concepts.
> >>
>
> >
> >Interested in patching?
> >
>
>
> You might be interested in the Commons Discovery project, which
> provides a standard (?) way to find implementations of a given
> interface. I am going to look into this as a possibility for
> streamlining the new XmlRpcTransport interface code I am working on
> with Andrew Evers.
>
>
> Project: http://jakarta.apache.org/commons/discovery.html
>
> Good place to get a quick and dirty idea of what this stuff does:
> http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
Would this dependency only be necessary on the server side, or would
it be a requirement on the client side as well?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>"Andrew Evers" <ae...@redwood.nl> writes:
>
>
>
>>>>From an overall embedding perspective it would be nice to specify
>>a property hash to a number of the constructors that could be
>>used to specify alternative classes for not only the type factory,
>>but also the request or response processor, or the worker. This
>>would provide more graceful construction as more optional features
>>are added.
>>
>>The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
>>API's use similar concepts.
>>
>>
>
>Interested in patching?
>
>
You might be interested in the Commons Discovery project, which provides
a standard (?) way to find implementations of a given interface. I am
going to look into this as a possibility for streamlining the new
XmlRpcTransport interface code I am working on with Andrew Evers.
Project: http://jakarta.apache.org/commons/discovery.html
Good place to get a quick and dirty idea of what this stuff does:
http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>"Andrew Evers" <ae...@redwood.nl> writes:
>
>
>
>>>From an overall embedding perspective it would be nice to specify
>>a property hash to a number of the constructors that could be
>>used to specify alternative classes for not only the type factory,
>>but also the request or response processor, or the worker. This
>>would provide more graceful construction as more optional features
>>are added.
>>
>>The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
>>API's use similar concepts.
>>
>>
>
>Interested in patching?
>
>
You might be interested in the Commons Discovery project, which provides
a standard (?) way to find implementations of a given interface. I am
going to look into this as a possibility for streamlining the new
XmlRpcTransport interface code I am working on with Andrew Evers.
Project: http://jakarta.apache.org/commons/discovery.html
Good place to get a quick and dirty idea of what this stuff does:
http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/discovery/DiscoverClass.html
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > Heya Andrew. I committed your code contribution, but used a class
> > loading pattern instead of the instance pattern you specified. This
> > allows one to supply new implementations of your TypeFactory interface
> > without writing sub-class of types.
> >
> > java -Dorg.apache.xmlrpc.TypeFactory=path.to.my.CustomTypeFactory ...
> >
> > Let me know if this suites you.
>
> I like the class loading pattern, but I'm not sure about the global
> nature of the system property. However, it is sufficient for our
> application.
That's a very good point. I would like having class loading as the
default behavior, but allow the flexibility of overriding that on a
case-by-case basis.
> >From an overall embedding perspective it would be nice to specify
> a property hash to a number of the constructors that could be
> used to specify alternative classes for not only the type factory,
> but also the request or response processor, or the worker. This
> would provide more graceful construction as more optional features
> are added.
>
> The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
> API's use similar concepts.
Interested in patching?
> > Did you ever happen to integrate JUnit tests for this functionality? --
>
> No, but it's on the list of stuff to do when I recover from jet-lag,
> along with finding my luggage ;)
Heh, damn throwers! On my last trip to Europe, they lost my luggage
in both directions.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > Heya Andrew. I committed your code contribution, but used a class
> > loading pattern instead of the instance pattern you specified. This
> > allows one to supply new implementations of your TypeFactory interface
> > without writing sub-class of types.
> >
> > java -Dorg.apache.xmlrpc.TypeFactory=path.to.my.CustomTypeFactory ...
> >
> > Let me know if this suites you.
>
> I like the class loading pattern, but I'm not sure about the global
> nature of the system property. However, it is sufficient for our
> application.
That's a very good point. I would like having class loading as the
default behavior, but allow the flexibility of overriding that on a
case-by-case basis.
> >From an overall embedding perspective it would be nice to specify
> a property hash to a number of the constructors that could be
> used to specify alternative classes for not only the type factory,
> but also the request or response processor, or the worker. This
> would provide more graceful construction as more optional features
> are added.
>
> The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
> API's use similar concepts.
Interested in patching?
> > Did you ever happen to integrate JUnit tests for this functionality? --
>
> No, but it's on the list of stuff to do when I recover from jet-lag,
> along with finding my luggage ;)
Heh, damn throwers! On my last trip to Europe, they lost my luggage
in both directions.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Andrew Evers <ae...@redwood.nl>.
> Heya Andrew. I committed your code contribution, but used a class
> loading pattern instead of the instance pattern you specified. This
> allows one to supply new implementations of your TypeFactory interface
> without writing sub-class of types.
>
> java -Dorg.apache.xmlrpc.TypeFactory=path.to.my.CustomTypeFactory ...
>
> Let me know if this suites you.
I like the class loading pattern, but I'm not sure about the global
nature of the system property. However, it is sufficient for our
application.
>From an overall embedding perspective it would be nice to specify
a property hash to a number of the constructors that could be
used to specify alternative classes for not only the type factory,
but also the request or response processor, or the worker. This
would provide more graceful construction as more optional features
are added.
The JNDI InitialContext and JAXP {SAXParser,DocumentBuilder}Factory
API's use similar concepts.
> Did you ever happen to integrate JUnit tests for this functionality? --
No, but it's on the list of stuff to do when I recover from jet-lag,
along with finding my luggage ;)
Andrew.
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Andrew Evers <ae...@redwood.nl>.
> Heya Andrew. I committed your code contribution, but used a class
> loading pattern instead of the instance pattern you specified. This
> allows one to supply new implementations of your TypeFactory interface
> without writing sub-class of types.
>
> java -Dorg.apache.xmlrpc.TypeFactory=path.to.my.CustomTypeFactory ...
>
> Let me know if this suites you.
I like the class loading pattern, but I'm not sure about the global
nature of the system property. However, it is sufficient for our
application.
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
<ae...@redwood.nl> writes:
> > Andrew, sounds interesting. Maintaing custom patches is never fun;
> > let's have a look at it.
>
> See attached patch TypeFactory-AE-20020809.txt and new files
> TypeFactory.java and TypeFactoryBase.java. This builds OK on
> my machine, and our product runs OK with it too.
>
> As far as the patch goes, I modified my original Integer only
> patch to support the other data types. I basically shifted the
> contents of the characterData method into the TypeFactoryBase
> class, along with the dateformat member, and removed the
> ParseException import in XmlRpc.
>
> I had to modify the XmlWriter as well, since it uses the XmlRpc
> dateformat member. This had a TODO next to it, so I just gave
> it its own dateformat member.
>
> I've modified XmlRpcServer and WebServer, but not SecureWebServer,
> that will come if the patch is accepted. It would be nice to
> have a factory for creating WebServer's anyway.
Heya Andrew. I committed your code contribution, but used a class
loading pattern instead of the instance pattern you specified. This
allows one to supply new implementations of your TypeFactory interface
without writing sub-class of types.
java -Dorg.apache.xmlrpc.TypeFactory=path.to.my.CustomTypeFactory ...
Let me know if this suites you.
> > JUnit tests for the existing interfaces and for any new code would be
> > VERY helpful as well.
>
> We use JUnit internally, so I think I could put together some basic
> tests:
> a) check that each of the methods in TypeFactory is called for a
> suitably crafted request.
> b) check the behaviour (with corner cases) of the TypeFactoryBase.
> c) check that an arbitrary TypeFactory instance doesn't throw
> an exception on an accepted set of 'legal' values.
>
> As far as tests for other interfaces go, I am interested in
> contributing both new code and more tests. I would like to
> look into restructuring the way decoding works so that thread
> handling on the server side can be better specified by the
> user. Ideally to allow the request and response to be handled
> by different threads.
Did you ever happen to integrate JUnit tests for this functionality?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: [PATCH]: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
<ae...@redwood.nl> writes:
> > Andrew, sounds interesting. Maintaing custom patches is never fun;
> > let's have a look at it.
>
> See attached patch TypeFactory-AE-20020809.txt and new files
> TypeFactory.java and TypeFactoryBase.java. This builds OK on
> my machine, and our product runs OK with it too.
>
> As far as the patch goes, I modified my original Integer only
> patch to support the other data types. I basically shifted the
> contents of the characterData method into the TypeFactoryBase
> class, along with the dateformat member, and removed the
> ParseException import in XmlRpc.
>
> I had to modify the XmlWriter as well, since it uses the XmlRpc
> dateformat member. This had a TODO next to it, so I just gave
> it its own dateformat member.
>
> I've modified XmlRpcServer and WebServer, but not SecureWebServer,
> that will come if the patch is accepted. It would be nice to
> have a factory for creating WebServer's anyway.
Heya Andrew. I committed your code contribution, but used a class
loading pattern instead of the instance pattern you specified. This
allows one to supply new implementations of your TypeFactory interface
without writing sub-class of types.
java -Dorg.apache.xmlrpc.TypeFactory=path.to.my.CustomTypeFactory ...
Let me know if this suites you.
> > JUnit tests for the existing interfaces and for any new code would be
> > VERY helpful as well.
>
> We use JUnit internally, so I think I could put together some basic
> tests:
> a) check that each of the methods in TypeFactory is called for a
> suitably crafted request.
> b) check the behaviour (with corner cases) of the TypeFactoryBase.
> c) check that an arbitrary TypeFactory instance doesn't throw
> an exception on an accepted set of 'legal' values.
>
> As far as tests for other interfaces go, I am interested in
> contributing both new code and more tests. I would like to
> look into restructuring the way decoding works so that thread
> handling on the server side can be better specified by the
> user. Ideally to allow the request and response to be handled
> by different threads.
Did you ever happen to integrate JUnit tests for this functionality?
--
Daniel Rall <dl...@finemaltcoding.com>
[PATCH]: Alternative type mappings for primitive types.
Posted by ae...@redwood.nl.
> Andrew, sounds interesting. Maintaing custom patches is never fun;
> let's have a look at it.
See attached patch TypeFactory-AE-20020809.txt and new files
TypeFactory.java and TypeFactoryBase.java. This builds OK on
my machine, and our product runs OK with it too.
As far as the patch goes, I modified my original Integer only
patch to support the other data types. I basically shifted the
contents of the characterData method into the TypeFactoryBase
class, along with the dateformat member, and removed the
ParseException import in XmlRpc.
I had to modify the XmlWriter as well, since it uses the XmlRpc
dateformat member. This had a TODO next to it, so I just gave
it its own dateformat member.
I've modified XmlRpcServer and WebServer, but not SecureWebServer,
that will come if the patch is accepted. It would be nice to
have a factory for creating WebServer's anyway.
> JUnit tests for the existing interfaces and for any new code would be
> VERY helpful as well.
We use JUnit internally, so I think I could put together some basic
tests:
a) check that each of the methods in TypeFactory is called for a
suitably crafted request.
b) check the behaviour (with corner cases) of the TypeFactoryBase.
c) check that an arbitrary TypeFactory instance doesn't throw
an exception on an accepted set of 'legal' values.
As far as tests for other interfaces go, I am interested in
contributing both new code and more tests. I would like to
look into restructuring the way decoding works so that thread
handling on the server side can be better specified by the
user. Ideally to allow the request and response to be handled
by different threads.
Andrew.
[PATCH]: Alternative type mappings for primitive types.
Posted by ae...@redwood.nl.
> Andrew, sounds interesting. Maintaing custom patches is never fun;
> let's have a look at it.
See attached patch TypeFactory-AE-20020809.txt and new files
TypeFactory.java and TypeFactoryBase.java. This builds OK on
my machine, and our product runs OK with it too.
As far as the patch goes, I modified my original Integer only
patch to support the other data types. I basically shifted the
contents of the characterData method into the TypeFactoryBase
class, along with the dateformat member, and removed the
ParseException import in XmlRpc.
I had to modify the XmlWriter as well, since it uses the XmlRpc
dateformat member. This had a TODO next to it, so I just gave
it its own dateformat member.
I've modified XmlRpcServer and WebServer, but not SecureWebServer,
that will come if the patch is accepted. It would be nice to
have a factory for creating WebServer's anyway.
> JUnit tests for the existing interfaces and for any new code would be
> VERY helpful as well.
We use JUnit internally, so I think I could put together some basic
tests:
a) check that each of the methods in TypeFactory is called for a
suitably crafted request.
b) check the behaviour (with corner cases) of the TypeFactoryBase.
c) check that an arbitrary TypeFactory instance doesn't throw
an exception on an accepted set of 'legal' values.
As far as tests for other interfaces go, I am interested in
contributing both new code and more tests. I would like to
look into restructuring the way decoding works so that thread
handling on the server side can be better specified by the
user. Ideally to allow the request and response to be handled
by different threads.
Andrew.
Re: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
<ae...@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.
http://jakarta.apache.org/site/source.html
JUnit tests for the existing interfaces and for any new code would be
VERY helpful as well.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Alternative type mappings for primitive types.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
<ae...@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.
http://jakarta.apache.org/site/source.html
JUnit tests for the existing interfaces and for any new code would be
VERY helpful as well.
--
Daniel Rall <dl...@finemaltcoding.com>