You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Holger Hoffstätte <ho...@wizards.de> on 2005/05/10 00:52:55 UTC
Please let XmlRpcRequestProcessor have a public Constructor
Hi,
Just some feedback on the API. :)
I'm in the situation that I manually need to create/encode/decode and
dispatch XML-RPC requests and responses. Encoding/decoding stuff was a
snap, but it would be nice if XmlRpcRequestProcessor had a public default
constructor. Right now it's protected and I cannot think of a good reason
for that. I need to get the XmlRpcServerRequest from an incoming byte[]
blob, and this seemed to be the Right Way.
I'd also like to see public constructors added to the other classes for
consistency; right now it's a rather unpretty mish-mash and not quite
clear which classes are fit for public consumption and which are not.
thanks,
Holger
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Jochen Wiedmann <jo...@gmail.com>.
Daniel L. Rall wrote:
> Can you tell us more about why you want to do this?
There are most possibly multiple use cases. For example, I had to do the
same, when writing a servlet with a complex mapping and authentication
scheme, that had to be truly thread safe.
Jochen
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Holger Hoffstätte <ho...@wizards.de>.
Daniel L. Rall wrote:
>>I'm in the situation that I manually need to create/encode/decode and
>>dispatch XML-RPC requests and responses. Encoding/decoding stuff was a
>
> Can you tell us more about why you want to do this?
I'm using an ESB called Mule (http://mule.codehaus.org/) for a
distressingly distributed and asynchronous project where I need to
integrate a server that is only accessible via perl API. Since I only need
a few well-defined calls and didn't want to start with all the SOAP
armwaving, I decided to use XML-RPC for that. Mule automatically routes
messages over various transports, and I wanted to create new xmlrpc://
transport plugin so that a message started on a Java client sent to a
local vm:// endpoint could be transformed (encoded, compressed,
whatever..), forwarded via HTTP to a server instance which does some more
processing (other systems via JMS are involved), and eventually ends up in
the perl server to trigger an action. Also the perl server is supposed to
send response events to another Java VM (running mule), and again I
figured it would be easiest to just use XML-RPC as transport for the endpoint.
Holger
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Tue, 2005-05-10 at 00:52 +0200, Holger Hoffstätte wrote:
> Hi,
>
> Just some feedback on the API. :)
> I'm in the situation that I manually need to create/encode/decode and
> dispatch XML-RPC requests and responses. Encoding/decoding stuff was a
> snap, but it would be nice if XmlRpcRequestProcessor had a public default
> constructor. Right now it's protected and I cannot think of a good reason
> for that. I need to get the XmlRpcServerRequest from an incoming byte[]
> blob, and this seemed to be the Right Way.
> I'd also like to see public constructors added to the other classes for
> consistency; right now it's a rather unpretty mish-mash and not quite
> clear which classes are fit for public consumption and which are not.
Can you tell us more about why you want to do this?
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Jochen Wiedmann <jo...@gmail.com>.
Holger Hoffstätte wrote:
> Glad you asked; patch against CVS HEAD is attached.
I must admit, that I was close to not committing this patch, because
your previous comment made me very angry (Who are you to question my
sense for software quality?), but I finally forced myself to do what I'd
most possibly do without it.
Jochen
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Holger Hoffstätte <ho...@wizards.de>.
Steve Quint wrote:
> Software quality also does not magically appear. Feel free to contribute.
Glad you asked; patch against CVS HEAD is attached.
-h
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Steve Quint <li...@nanohertz.com>.
At 8:46 AM +0200 5/10/05, Holger Hoffstätte wrote:
>
> Software quality is not a crime, you know.
Software quality also does not magically appear. Feel free to contribute.
--
Steve
------------------------------------------------------------
"Always ... always remember: Less is less. More is more. More is
better. And twice as much is good too. Not enough is bad. And too
much is never enough except when it's just about right."
-- The Tick
------------------------------------------------------------
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Holger Hoffstätte <ho...@wizards.de>.
Jochen Wiedmann wrote:
> No reason for that: Just create a subclass and use that.
Yes, and I can use XmlRpcRequest, XmlRpcResponseProcessor and
XmlRpcClientResponseProcessor without subclassing why?
OTOH I'm glad you didn't suggest I put all my classes into the .xmlrpc.*
namespace. Software quality is not a crime, you know.
-h
Re: Please let XmlRpcRequestProcessor have a public Constructor
Posted by Jochen Wiedmann <jo...@gmail.com>.
No reason for that: Just create a subclass and use that.