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 Kevin Hester <ke...@ispiri.com> on 2002/08/21 17:27:13 UTC
Making Invoker public?
Hi,
Yesterday I began using the Apache XML-RPC library, and I must give praise:
This is a great library - it works well and it is very cleanly constructed.
However, I have run into one issue and I'd like to see if you want my fix.
I have a number of objects which are currently using RMI, and as such they
have methods declared as void. I've decided to encapsulate these objects in
an XML-RPC framework, but I would still like to have the option of using RMI.
Everything works great except that the void functions return null when
invoked through the introspection API.
It seemed to me that creating a glue class that implements the XmlRpcHandler
and uses introspection would be an ideal solution to this problem. The glue
class could invoke the method on its target object, check for null return
value and substitute a value which is acceptable in XML-RPC land (i.e.
Integer(0)).
Of course, the glue class I'm describing is only a slight modification of
Invoker.
My solution: Make the invoker class public so that users can subclass it for
custom behavior. In my case, I override execute to check for a null return
value.
My question to all:
1) Does this seem like a good solution? It sure seems better than people
having to reinvent the introspection glue.
2) Do you want diffs for this minor change?
Kevin
--
Kevin Hester
kevinh@ispiri.com Ispiri Development
Re: Making Invoker public?
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Kevin Hester <ke...@ispiri.com> writes:
> Hi,
Hi Kevin.
> Yesterday I began using the Apache XML-RPC library, and I must give praise:
> This is a great library - it works well and it is very cleanly constructed.
> However, I have run into one issue and I'd like to see if you want my fix.
>
> I have a number of objects which are currently using RMI, and as such they
> have methods declared as void. I've decided to encapsulate these objects in
> an XML-RPC framework, but I would still like to have the option of using RMI.
> Everything works great except that the void functions return null when
> invoked through the introspection API.
>
> It seemed to me that creating a glue class that implements the XmlRpcHandler
> and uses introspection would be an ideal solution to this problem. The glue
> class could invoke the method on its target object, check for null return
> value and substitute a value which is acceptable in XML-RPC land (i.e.
> Integer(0)).
This sounds like a nice extension. I'm not sure it's something that
we want on by default, but I wouldn't be against finding some way to
include it in the package.
> Of course, the glue class I'm describing is only a slight modification of
> Invoker.
>
> My solution: Make the invoker class public so that users can subclass it for
> custom behavior. In my case, I override execute to check for a null return
> value.
Andrew Evers is currently working on refactoring the XmlRpcServer
class, splitting on its child classes and making it more reusable. It
would be terrific if you could grab this small chunk of the work which
he has proposed. See his recent message for details:
http://archives.apache.org/eyebrowse/ReadMsg?listName=rpc-dev@xml.apache.org&msgNo=227
> My question to all:
>
> 1) Does this seem like a good solution? It sure seems better than people
> having to reinvent the introspection glue.
Yeah, sounds useful.
> 2) Do you want diffs for this minor change?
I defer to Andrew. You guys can work it out. :-)
--
Daniel Rall <dl...@finemaltcoding.com>
Re: Making Invoker public?
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Kevin Hester <ke...@ispiri.com> writes:
> Hi,
Hi Kevin.
> Yesterday I began using the Apache XML-RPC library, and I must give praise:
> This is a great library - it works well and it is very cleanly constructed.
> However, I have run into one issue and I'd like to see if you want my fix.
>
> I have a number of objects which are currently using RMI, and as such they
> have methods declared as void. I've decided to encapsulate these objects in
> an XML-RPC framework, but I would still like to have the option of using RMI.
> Everything works great except that the void functions return null when
> invoked through the introspection API.
>
> It seemed to me that creating a glue class that implements the XmlRpcHandler
> and uses introspection would be an ideal solution to this problem. The glue
> class could invoke the method on its target object, check for null return
> value and substitute a value which is acceptable in XML-RPC land (i.e.
> Integer(0)).
This sounds like a nice extension. I'm not sure it's something that
we want on by default, but I wouldn't be against finding some way to
include it in the package.
> Of course, the glue class I'm describing is only a slight modification of
> Invoker.
>
> My solution: Make the invoker class public so that users can subclass it for
> custom behavior. In my case, I override execute to check for a null return
> value.
Andrew Evers is currently working on refactoring the XmlRpcServer
class, splitting on its child classes and making it more reusable. It
would be terrific if you could grab this small chunk of the work which
he has proposed. See his recent message for details:
http://archives.apache.org/eyebrowse/ReadMsg?listName=rpc-dev@xml.apache.org&msgNo=227
> My question to all:
>
> 1) Does this seem like a good solution? It sure seems better than people
> having to reinvent the introspection glue.
Yeah, sounds useful.
> 2) Do you want diffs for this minor change?
I defer to Andrew. You guys can work it out. :-)
--
Daniel Rall <dl...@finemaltcoding.com>