xmlrpc-developers — Discussions regarding the implementation of the library.

[Xmlrpc-developers] developing asynchronous java XML-rpc calls using redstone

[Nandhakumar G. <Nan...@s-...>]

Hi,

I am new to redstone XML-RPC. Could anybody please let me  know how can I create asynchronous XML-RPC clients using redstone.

I would like to see some sample codes, with XmlRpcClient and XmlRpcProxy.

Many thanks,
Nandhakumar

[Xmlrpc-developers] Convenient and private ordering!

[<pap...@ms...>]

Your girl can't keep her hands off you! http://82.41.117.151/agtu/

[Xmlrpc-developers] The baby-maker grows and develops GRADUALLY, not over night!

[<mon...@so...>]

Large PE is not a dream anymore! http://69.105.55.250/oo/

[Xmlrpc-developers] No Pumps, be ready while she is taking a shower!

[<joa...@cj...>]

Your health is at stake! http://azpp.owndeep.com

[Xmlrpc-developers] My Love

[<va...@ex...>]

Love Remains http://92.80.249.93/

[Xmlrpc-developers] Ringing you up to wish a Happy New Year 2008

[<ap...@st...>]

Greeting you the earliest with my heartiest New 2008 Year wishes
http://freshcards2008.com/

[Xmlrpc-developers] Happy New Year!

[<eug...@he...>]

New Year Ecard
http://uhavepostcard.com/

[Xmlrpc-developers] I played with this for hours

[<mar...@he...>]

I am sending this to everyone. It is so cute. http://219.248.255.86/

[Xmlrpc-developers] Man this is funny

[<avi...@ne...>]

Take 5 min out this will make you feel better. http://80.181.121.225/

[Xmlrpc-developers] This is hilarious!

[<ro...@ma...>]

Someone sent you this Psycho Kitty card. It is Hilarious!
http://88.65.82.101/

[Xmlrpc-developers] Your ecard horoscope is waiting!

[<aa...@ki...>]

Kitty Kards, sent just for you. http://71.192.147.64/

[Xmlrpc-developers] Lets get ready to go

[<sh...@jh...>]

PPYH Shifts Direction And Investor Interest Renewed.

Physical Property Holdings Inc.
PPYH
$0.25

Restructure at Physical is taking off as they begin hitting the HK Real
Estate Market. News releases have already begun listing there
acquisitions, and the target list is getting bigger. This is not one to
overlook, call your broker and get him on this before opening bell on
Monday.

[Xmlrpc-developers] 10 seconds to check out these games

[<ha...@uc...>]

Free games, What more do we need to say? http://67.149.51.30/

[Xmlrpc-developers] take 15 min and play a game

[<cat...@fa...>]

What can we say, we got free games. over 1000 of them. check it out!
http://87.228.62.109/

[Xmlrpc-developers] Java 1.4 compatible version

[Jesus M. R. <jm...@gm...>]

I have a few questions for the authors:

1) can I fork marquee-xmlrpc?
2) can I fork redstone-xmlrpc so that it can be built using java 1.4?

Sincerely,
jesus rodriguez

[Xmlrpc-developers] SimpleXmlRpcClient

[Alessandro V. <ar...@ti...>]

Hi, noob question...

Is there an equivalent in SimpleSmlRpcClient to the non-Simple  
XmlRpcClient method setBasicAuthentication,  which looks necessary  
for serious eXist xmlrpc manipulation? And what about setEncoding?

Thanks...
Alessandro Volz

[Xmlrpc-developers] Maintained???

[Michael B. <mb...@re...>]

Is this project being maintained by anyone? Is anybody actively working 
on it?

We've been using Marquee for our xml-rpc layer, but there are a few 
enhancements we need. We submitted a patch a few months ago that seems 
to be just sitting there. I also notice many bugs and RFE's just hanging 
out...

Thanks,
-Michael
-- 
Michael C. Bowman
Red Hat - RHN Web Engineer
mb...@re...

[Xmlrpc-developers] Help - to build xml-rpc project

[Geeta P. S. <ge...@in...>]

Hello,

 

We are trying to build Marquee XMLRPC Project. We have downloaded (1.3 from
August 5, 2002)

Java: client/server (Greger Ohlson) from
http://xmlrpc.scripting.com/directory/1568/implementations

 

We are using JDK version java version "1.3.1_02"

Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)

Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)

Ant version - Apache Ant version 1.6.2 compiled on July 16 2004

When we try to build xmlrpc project we get the following errors

1. D:\jdk1.3.1_06\xmlrpc>ant

Buildfile: build.xml

classes:

    [javac] Compiling 10 source files to D:\jdk1.3.1_06\xmlrpc\build\classes

BUILD FAILED

java.lang.UnsupportedClassVersionError: com/sun/tools/javac/Main
(Unsupported major.minor version 48.0)

Total time: 2 seconds

Can you please help us with this? Thanks!

Regards,
Geeta Sonavane
Senior Consultant
InteractCRM
http://www.interactcrm.com <http://www.interactcrm.com/> 
O:+91.22.56959190

 

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

[Doug O. <do...@pl...>]

Greger Ohlson writes:
 > You may now register aliases that map to a fully
 > qualified XML-RPC method name:
 > 
 >   server.registerInvocationHandler( "MyHandler", myHandler );
 >   server.registerInvocationHandlerAlias( "echo", "MyHandler.echo" );
 >   server.registerInvocationHandlerAlias( "sum", "MyHandler.sum" );

This works well, thanks!  It would also be nice if a similar thing
were available for XmlRpcProxy, which currently only sends methodNames
with dots.

 > If requested, the XmlRpcServer could be expanded to reflectively
 > add aliases given an XmlRpcInvocationHandler like so:
 > 
 >   server.registerInvocationHandlerAliases( myHandler );
 > 
 > This would then create aliases automatically for each method
 > name in the handler.

This would be convenient, yes.  Again, something similar for
XmlRpcProxy would be great too.

--...@pl...

[Xmlrpc-developers] patch: factor out HTTP transport layer

[Doug O. <do...@pl...>]

Greger Ohlson writes:
 > You can also send me the patches you've made, and I'll introduce
 > them in the code base.

OK, here are some diffs for what I've been working on (at the bottom
of this message).  You should be able to feed them directly to `patch'.

Summary: I'm implementing Jabber-RPC, which uses the same message
syntax as XML-RPC but uses XMPP as its transport layer instead of HTTP.
http://www.jabber.org/jeps/jep-0009.html
There are two main problems with the Marquee XML-RPC library that
prevent me from using it as-is:

1. XmlRpcClient and XmlRpcProxy are hardcoded to connect to an HTTP
   server, either using a URL object or a host, port, and path.
   Instead I need to send the message to a Jabber user ID (JID) using
   an XMPP connection to a Jabber server.
2. XmlRpcClient and XmlRpcDispatcher are hardcoded to prefix the
   XML-RPC message with "<?xml ... ?>", since the message is meant to
   be a complete XML document inside the HTTP post and reply.
   However, in Jabber-RPC the message is part of a larger XML document
   (the XMPP stream) and it is an error to include the "<?xml ... ?>"
   element.

Fortunately, the first problem was easy to address, because most of
the HTTP-related code is factored out and hidden behind the
XmlRpcClientConnectionFactory interface.  I just added a new public
constructor to XmlRpcClient that takes an
XmlRpcClientConnectionFactory as an argument, so that I can provide my
own instance that uses XMPP instead of HTTP.  I also added a new
createProxy method to XmlRpcProxy that takes an XmlRpcClient object.

The second problem was not too difficult to fix either, although my
solution may not be the most elegant.  I just added optional boolean
arguments requestIsXmlDocument and responseIsXmlDocument to the
XmlRpcClient constructor and the dispatch methods on XmlRpcServer and
XmlRpcDispatcher, respectively, which default to true.  A better
solution might be to add a method to the XmlRpcClientConnection
interface that determines whether messages sent using that connection
should be encoded as complete XML documents or not, but I was hesitant
about adding methods to an interface.

Anyway, feel free to rewrite any of these changes, or to improve the
comments or whatever.  Let me know if you have any questions.

Also, let me know if I should be sending these diffs directly to you,
or if I should continue sending them to the developers list also.

--...@pl...


diffs start here:


Index: marquee/xmlrpc/XmlRpcClient.java
===================================================================
RCS file: /cvsroot/xmlrpc/xmlrpc/source/marquee/xmlrpc/XmlRpcClient.java,v
retrieving revision 1.13
diff -c -r1.13 XmlRpcClient.java
*** marquee/xmlrpc/XmlRpcClient.java	18 Sep 2003 14:24:14 -0000	1.13
--- marquee/xmlrpc/XmlRpcClient.java	11 Feb 2004 19:14:19 -0000
***************
*** 77,83 ****
          final String host,
          final int port,
          final String path) {
!         connectionFactory = new SocketConnectionFactory(host, port, path);
      }
  
      /**
--- 77,83 ----
          final String host,
          final int port,
          final String path) {
!         this(new SocketConnectionFactory(host, port, path), true);
      }
  
      /**
***************
*** 88,96 ****
       */
  
      public XmlRpcClient(final URL url) {
!         connectionFactory = new URLConnectionFactory(url);
      }
  
      /**
       *  Determines  if  the  most previously XML-RPC response contained a
       *  fault struct, in which case the return value of the most previous
--- 88,114 ----
       */
  
      public XmlRpcClient(final URL url) {
!         this(new URLConnectionFactory(url), true);
      }
  
+ 
+     /**
+      *  Creates a new client with the ability to send XML-RPC messages
+      *  across connections created by the given connection factory.
+      *
+      *  @param factory the connection factory used to create connections
+      *  @param requestIsXmlDocument should the XML-RPC request be a
+      *  complete XML document?
+      *
+      */
+     public XmlRpcClient(final XmlRpcClientConnectionFactory factory,
+                         boolean requestIsXmlDocument)
+     {
+       connectionFactory = factory;
+       this.requestIsXmlDocument = requestIsXmlDocument;
+     }
+ 
+ 
      /**
       *  Determines  if  the  most previously XML-RPC response contained a
       *  fault struct, in which case the return value of the most previous
***************
*** 279,285 ****
      private void beginCall(String method) {
          xmlBuffer.setLength(0);
  
!         xmlBuffer.append("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>").append("<methodCall><methodName>") //$NON-NLS-1$
          .append(method).append("</methodName><params>"); //$NON-NLS-1$
  
          isFaultResponse = false; // Until we're proven otherwise.
--- 297,305 ----
      private void beginCall(String method) {
          xmlBuffer.setLength(0);
  
!         if (requestIsXmlDocument)
!           xmlBuffer.append("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>");
!         xmlBuffer.append("<methodCall><methodName>") //$NON-NLS-1$
          .append(method).append("</methodName><params>"); //$NON-NLS-1$
  
          isFaultResponse = false; // Until we're proven otherwise.
***************
*** 429,434 ****
--- 449,457 ----
  
      /** The factory that creates connections to the server */
      private XmlRpcClientConnectionFactory connectionFactory;
+ 
+     /** Should the XML-RPC request be a complete XML document? */
+     private boolean requestIsXmlDocument;
  
      /** The connection we use to talk to the server */
      private XmlRpcClientConnection connection;
Index: marquee/xmlrpc/XmlRpcDispatcher.java
===================================================================
RCS file: /cvsroot/xmlrpc/xmlrpc/source/marquee/xmlrpc/XmlRpcDispatcher.java,v
retrieving revision 1.13
diff -c -r1.13 XmlRpcDispatcher.java
*** marquee/xmlrpc/XmlRpcDispatcher.java	11 Feb 2004 11:32:43 -0000	1.13
--- marquee/xmlrpc/XmlRpcDispatcher.java	11 Feb 2004 19:14:19 -0000
***************
*** 98,103 ****
--- 98,125 ----
          dispatchers.push(this);
      }
  
+     /**
+ 	 * Inbound  XML-RPC  messages  to  a  server are delegated to this
+ 	 * method.  It  performs  the  parsing of the message, through the
+ 	 * inherited   parse()   method,   and  locates  and  invokes  the
+ 	 * appropriate invocation handlers.
+      * 
+ 	 * @throw  Exception When the inbound XML message cannot be parsed
+ 	 * due  to no available SAX driver, or when an invalid message was
+ 	 * received.  All  other  exceptions are caught and encoded within
+ 	 * the XML-RPC response.
+ 	 * 
+      * @param xmlInput
+      * @return
+      * @throws Throwable
+      */
+ 
+     public byte[] dispatch(InputStream xmlInput)
+       throws Throwable
+     {
+         return dispatch(xmlInput, true);
+     }
+ 
  
      /**
  	 * Inbound  XML-RPC  messages  to  a  server are delegated to this
***************
*** 111,122 ****
  	 * the XML-RPC response.
  	 * 
       * @param xmlInput
       * @return
       * @throws Throwable
       */
  
!     public byte[] dispatch(InputStream xmlInput) throws Throwable
      {
          arguments.clear();
  
          // Parse the inbound XML-RPC message. May throw an exception.
--- 133,147 ----
  	 * the XML-RPC response.
  	 * 
       * @param xmlInput
+      * @param responseIsXmlDocument should the response be an XML document?
       * @return
       * @throws Throwable
       */
  
!     public byte[] dispatch(InputStream xmlInput, boolean responseIsXmlDocument)
!       throws Throwable
      {
+         this.responseIsXmlDocument = responseIsXmlDocument;
          arguments.clear();
  
          // Parse the inbound XML-RPC message. May throw an exception.
***************
*** 352,360 ****
  
      private void writeResponse(Object value) {
          response.setLength(0);
!         response.append(
!             "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>"
!                 + "<methodResponse><params><param>");
  
          if (value != null) {
              try {
--- 377,385 ----
  
      private void writeResponse(Object value) {
          response.setLength(0);
! 	if (responseIsXmlDocument)
!           response.append("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>");
!         response.append("<methodResponse><params><param>");
  
          if (value != null) {
              try {
***************
*** 382,390 ****
  
      private void writeError(String message) {
          response.setLength(0);
          response.append(
!             "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>"
!                 + "<methodResponse><fault><value><struct>"
                  + "<member><name>faultCode</name><value><int>-1</int></value>"
                  + "</member><member><name>faultString</name><value><string>");
          response.append(message);
--- 407,416 ----
  
      private void writeError(String message) {
          response.setLength(0);
+ 	if (responseIsXmlDocument)
+ 	  response.append("<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>");
          response.append(
!             "<methodResponse><fault><value><struct>"
                  + "<member><name>faultCode</name><value><int>-1</int></value>"
                  + "</member><member><name>faultString</name><value><string>");
          response.append(message);
***************
*** 412,417 ****
--- 438,446 ----
  
      /** Holds the XML-RPC repsonse as it is built up */
      private StringBuffer response = new StringBuffer(2048);
+ 
+     /** Should the response be an XML document? */
+     private boolean responseIsXmlDocument = true;
  }
  
  /*
Index: marquee/xmlrpc/XmlRpcProxy.java
===================================================================
RCS file: /cvsroot/xmlrpc/xmlrpc/source/marquee/xmlrpc/XmlRpcProxy.java,v
retrieving revision 1.8
diff -c -r1.8 XmlRpcProxy.java
*** marquee/xmlrpc/XmlRpcProxy.java	18 Sep 2003 12:55:00 -0000	1.8
--- marquee/xmlrpc/XmlRpcProxy.java	11 Feb 2004 19:14:20 -0000
***************
*** 116,127 ****
          String objectName,
          Class[] interfaces ) throws XmlRpcException
      {
!         checkInterfaces( interfaces, XmlRpcException.class );
! 
!         return Proxy.newProxyInstance(
!             interfaces[ 0 ].getClassLoader(),
!             interfaces,
!             new XmlRpcProxy( host, port, path, objectName ) );
      }
  
  
--- 116,125 ----
          String objectName,
          Class[] interfaces ) throws XmlRpcException
      {
!         return createProxy(
!             new XmlRpcClient( host, port, path ),
!             objectName,
!             interfaces );
      }
  
  
***************
*** 175,186 ****
          String objectName,
          Class[] interfaces ) throws XmlRpcException
      {
          checkInterfaces( interfaces, XmlRpcException.class );
  
          return Proxy.newProxyInstance(
              interfaces[ 0 ].getClassLoader(),
              interfaces,
!             new XmlRpcProxy( url, objectName ) );
      }
  
  
--- 173,215 ----
          String objectName,
          Class[] interfaces ) throws XmlRpcException
      {
+         return createProxy(
+             new XmlRpcClient(url),
+             objectName,
+             interfaces );
+     }
+ 
+ 
+     /**
+      *  Creates a new dynamic proxy object that implements all
+      *  supplied interfaces.  This object may be type cast to any of
+      *  the interface supplied in the call.  Method calls through the
+      *  interfaces will be translated to XML-RPC calls to the server
+      *  via the supplied client.
+      *
+      *  @param client The XML-RPC client that will send calls
+      *
+      *  @param interfaces The list of interfaces the proxy should
+      *                    implement
+      *
+      *  @param objectName The name under which the handler is
+      *                    reachable
+      *
+      *  @return An object implementing the supplied interfaces with
+      *          XML-RPC support
+      */
+ 
+     public static Object createProxy(
+         XmlRpcClient client,
+         String objectName,
+         Class[] interfaces ) throws XmlRpcException
+     {
          checkInterfaces( interfaces, XmlRpcException.class );
  
          return Proxy.newProxyInstance(
              interfaces[ 0 ].getClassLoader(),
              interfaces,
!             new XmlRpcProxy( client, objectName ));
      }
  
  
***************
*** 396,423 ****
       */
  
      protected XmlRpcProxy(
!         String host,
!         int port,
!         String path,
          String objectName )
      {
!         client = new XmlRpcClient( host, port, path );
          this.objectName = objectName;
      }
  
- 
-     /**
-      *  Creates a new XmlRpcProxy whis is a dynamic proxy invocation handler with
-      *  an encapsulated XmlRpcCLient. Not for pubilc usage -- use createProxy()
-      */
- 
-     protected XmlRpcProxy(
-         URL url,
-         String objectName )
-     {
-         client = new XmlRpcClient( url );
-         this.objectName = objectName;
-     }
  
  
      /**
--- 425,437 ----
       */
  
      protected XmlRpcProxy(
!         XmlRpcClient client,
          String objectName )
      {
!         this.client = client;
          this.objectName = objectName;
      }
  
  
  
      /**
Index: marquee/xmlrpc/XmlRpcServer.java
===================================================================
RCS file: /cvsroot/xmlrpc/xmlrpc/source/marquee/xmlrpc/XmlRpcServer.java,v
retrieving revision 1.9
diff -c -r1.9 XmlRpcServer.java
*** marquee/xmlrpc/XmlRpcServer.java	11 Feb 2004 11:28:29 -0000	1.9
--- marquee/xmlrpc/XmlRpcServer.java	11 Feb 2004 19:14:20 -0000
***************
*** 131,139 ****
      public byte[] execute(
          InputStream xmlInput ) throws Throwable
      {
          XmlRpcDispatcher dispatcher = XmlRpcDispatcher.getDispatcher( this, "(unknown)" );
  
!         byte[] result = dispatcher.dispatch( xmlInput );
          dispatcher.release();
  
          return result;
--- 131,163 ----
      public byte[] execute(
          InputStream xmlInput ) throws Throwable
      {
+         return execute(xmlInput, true);
+     }
+ 
+ 
+     /**
+      *  Dispatches the call contained in the supplied input stream. The stream should contain
+      *  a proper XML message conforming to the XML-RPC specification.
+      *
+      *  @param xmlInput The XML-RPC message.
+      *
+      *  @param responseIsXmlDocument Should the XML-RPC response be a
+      *         complete XML document?
+      *
+      *  @throws Throwable if the input stream contains unparseable XML or if some error
+      *          occurs in the SAX driver.
+      *
+      *  @return An array of bytes representing the XML-RPC response. Any exception occuring
+      *          in the invocation handlers are embedded in the XML-RPC response.
+      */
+ 
+     public byte[] execute(
+         InputStream xmlInput,
+         boolean responseIsXmlDocument) throws Throwable
+     {
          XmlRpcDispatcher dispatcher = XmlRpcDispatcher.getDispatcher( this, "(unknown)" );
  
!         byte[] result = dispatcher.dispatch( xmlInput, responseIsXmlDocument );
          dispatcher.release();
  
          return result;

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

[Doug O. <do...@pl...>]

Greger Ohlson writes:
 > The suggested functionality now exists in the HEAD revision of
 > the CVS.

Wow, quick service, thanks!  I will try it out and see how it works.
I hadn't yet thought about how to change the interface, I was just
thinking about whether it needed to be changed...  I'll let you know
if I have any suggestions, but what you did looks pretty good at first
glance.

--...@pl...

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

[Greger O. <gre...@ma...>]

Hi again,

The suggested functionality now exists in the HEAD revision of
the CVS. You may now register aliases that map to a fully
qualified XML-RPC method name:

  server.registerInvocationHandler( "MyHandler", myHandler );
  server.registerInvocationHandlerAlias( "echo", "MyHandler.echo" );
  server.registerInvocationHandlerAlias( "sum", "MyHandler.sum" );

The dispatcher will check all method names against the
alias map before performing the function call. In the example
above, all messages with method name "echo" will expand
to "MyHandler.echo" before being processed.

If requested, the XmlRpcServer could be expanded to reflectively
add aliases given an XmlRpcInvocationHandler like so:

  server.registerInvocationHandlerAliases( myHandler );

This would then create aliases automatically for each method
name in the handler. Registering aliases manually, though,
allows you to substitute the name of a method for another:

  server.registerInvocationHandlerAlias( "sumIntegers", "MyHandler.sum"
);

Hope this helps you, Doug. I leave the automatic aliasing for now.

Regards,
Greger Ohlson.

-----Ursprungligt meddelande-----
Fr=E5n: xml...@li...
[mailto:xml...@li...] F=F6r
ext...@ti...
Skickat: den 11 februari 2004 10:18
Till: do...@pl...; xml...@li...
=C4mne: RE: [Xmlrpc-developers] dots in XML-RPC method names


Hmmm... gave this some more thought. Perhaps the easiest
way would be to use aliases all the way? That is, the
server allows you to register aliases for "Handler.method"
names. Would this be a good solution for you? That is;

  server.registerInvocationHandler( "MyHandler", myHandler );
  server.registerInvocationAlias( "echo", "MyHandler.echo" );
  server.registerInvocationAlias( "sum", "MyHandler.sum" );

(Normal dispatching works as before by invoking "MyHandler.echo",
 and invoking just "echo" would map to "MyHandler.echo")

This would be equally simple to implement as the first proposal,
and it would be more flexible. When an XML-RPC message is
to be dispatched, where the method name does not contain
a dot, the dispatcher treats the method name as an alias
that is resolved by the server. This would allow the
alias to contain any character sequence, except dots.

The dispatcher could also be modified so that it always
checks to see if the method name is a registered alias,
in which case it is replaced by the alias mapping. This
would allow aliases that contains dots. Equally simple
to implement, but would require a Map lookup for every
invocation (extremely cheap, though, considering the XML and
TCP/IP overhead).

I think this would be best, what do you think?

Regards,
Greger.

-----Original Message-----
From: Olsson Greger (ext)=20
Sent: den 11 februari 2004 09:51
To: do...@pl...; xml...@li...
Subject: RE: [Xmlrpc-developers] dots in XML-RPC method names



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


-------------------------------------------------------
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


-------------------------------------------------------
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

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

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

Hmmm... gave this some more thought. Perhaps the easiest
way would be to use aliases all the way? That is, the
server allows you to register aliases for "Handler.method"
names. Would this be a good solution for you? That is;

  server.registerInvocationHandler( "MyHandler", myHandler );
  server.registerInvocationAlias( "echo", "MyHandler.echo" );
  server.registerInvocationAlias( "sum", "MyHandler.sum" );

(Normal dispatching works as before by invoking "MyHandler.echo",
 and invoking just "echo" would map to "MyHandler.echo")

This would be equally simple to implement as the first proposal,
and it would be more flexible. When an XML-RPC message is
to be dispatched, where the method name does not contain
a dot, the dispatcher treats the method name as an alias
that is resolved by the server. This would allow the
alias to contain any character sequence, except dots.

The dispatcher could also be modified so that it always
checks to see if the method name is a registered alias,
in which case it is replaced by the alias mapping. This
would allow aliases that contains dots. Equally simple
to implement, but would require a Map lookup for every
invocation (extremely cheap, though, considering the XML and
TCP/IP overhead).

I think this would be best, what do you think?

Regards,
Greger.

-----Original Message-----
From: Olsson Greger (ext)=20
Sent: den 11 februari 2004 09:51
To: do...@pl...; xml...@li...
Subject: RE: [Xmlrpc-developers] dots in XML-RPC method names



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


-------------------------------------------------------
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

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

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

[Doug O. <do...@pl...>]

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).  

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...