xml-rpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: [PATCH]: Alternative type mappings for primitive types.
Date Fri, 27 Sep 2002 18:41:14 GMT
<aevers@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 <dlr@finemaltcoding.com>

Mime
View raw message