RE: [Xmlrpc-developers] dots in XML-RPC method names

[<ext...@ti...>]

Hi Doug,

This restriction stems from the fact that Java is an object
oriented language. In the library, you register objects as
invocation handlers, under a particualt handler/service name,
and the dot notation is used to determine which method in
the handler to invoke.

If the <methodName> element would only contain the method
name part, ecluding the handler name, this information would
have to be inferred by some other mechanism. It would be
possible to rewrite the XmlRpcDispatcher to recognize method
names that do not include a handler part. The dispatcher could
then collect a handler registered under the same name as
the method name, and also invoke the method with that name
on the handler.

Example:

class MyHandler
{
    public Object echo( Object object ) { return object; }
    public int sum( int a, int b ) { return a + b; }
}

Normally, an object of this class would be registered under
a handler name in the XmlRpcServer. The dot notation would
then indicate which of the methods, echo or sum, to invoke.
An alternative would be to register the handler object
under more that one name, in this case under the names
"echo" and "sum". That is;

XmlRpcServer server =3D new XmlRpcServer();
XmlRpcInvocationHandler handler =3D new ReflectiveInvocationHandler( new =
MyHandler() );

server.registerInvocationHandler( "MyHandler", handler );
server.registerInvocationHandler( "echo", handler );
server.registerInvocationHandler( "sum", handler );

The dispatcher would recogninze a call to "MyHandler.echo" in
the normal way, and locate the handler registerd under "MyHandler",
and invoke its "echo" method. It would also recognize that the
method name does not use dot notation and locate the handler
registered under the name "echo", and also invoking the method
on it named "echo".

This is the easiest way I can think of. It requires minimum
modifications to XmlRpcDispatcher and everything will work.
However, it requires that each "plain method" you want to support
is registered in the server like in the example above.
To make this simple, a XmlRpcServer.registerMethods( =
XmlRpcInvocationHandler )
could be introduced that registers all methods in the handler under =
their
names. Note that in either case, no two handlers may contain
methods with the same name. No overloading is supported.

I can fix this tonight if you'd like. A nicer way would be to
be able to map a handler and a method to an alias, but that
would be harder to implement:

  server.registerInvocationEntryPoint( "sumInts", myHandler, "sum" );
  server.registerInvocationEntryPoint( "sumDoubles", myOtherHandler, =
"sum" );

In this case, "sumInts", and "sumDoubles" would be published. When
invoked, they would map to the "sum" method of myHandler and =
myOtherHandler,
respectively. Like I said, however, this would require more work.

Regards,
Greger.

-----Original Message-----
From: Doug Orleans [mailto:do...@pl...]
Sent: den 10 februari 2004 19:55
To: xmlrpc-developers
Subject: [Xmlrpc-developers] dots in XML-RPC method names


As far as I can tell, the XML-RPC spec does not require that a method
name (i.e. the contents of a <methodName> element) have a dot in it.
However, the marquee.xmlrpc.XmlRpcDispatcher class requires this,
returning an error "Invalid method name format" if the requested
method name doesn't contain a dot.  (This is only for the server side;
marquee.xmlrpc.XmlRpcClient allows any arbitrary string). =20

Was it an intentional design decision to be more restrictive than the
XML-RPC spec?  The "service.method" naming convention seems to be
widespread, but is this actually specified anywhere as a convention
that XML-RPC implementations ought to enforce?  Or was this just an
oversight in the implementation of the Marquee library?  If so, is it
something you're planning to fix, or has nobody noticed it before?

I'm asking because the project I'm working on already chose an RPC
protocol that involved plain method names (without dots), and I'd
have to modify the Marquee library to allow it, but I'm wondering if
instead I should convince the others on the project to change the
protocol to switch to the "service.method" naming convention.
If this convention is more than just a de facto standard, they might
be more willing to switch.

Thanks,
--Doug Orleans
do...@pl...


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xmlrpc-developers mailing list
Xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlrpc-developers