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/09 10:56:58 UTC
[PATCH]: Alternative type mappings for primitive types.
> 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: [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>