Re: XML-RPC Question

[Jochen Wiedmann <jo...@gmail.com>]

Hi, Josef,

first of all, the proper places for such discussions are the xmlrpc-dev 
or -user mailing lists. I am cc'ing the former.

The response encoding is done by the class XmlRpcWriter. To achieve your 
target, create a subclass of XmlRpcWriter and overwrite the method 
writeObject, roughly like this:

          public void writeObject(Object obj) {
              if (obj instanceof String) {
                  startElement("value");
                  startElement("string");
                  chardata(obj.toString());
                  endElement("string");
                  endElement("value");
              } else {
                  super.writeObject(obj);
              }
          }

Unfortunately, XmlRpcWriter is not a public or protected class. In other 
words, your subclass needs to reside in the package org.apache.xmlrpc, 
which is obviously not good.

The main problem is, how to ensure that your modified writer is being 
used. Currently, you have to subclass the XmlRpcResponseProcessor and 
overwrite the methods encodeResponse and encodeException. Unfortunately, 
it seems that reusing the superclasses methods is not possible here, so 
you have to copy the entire methods into your subclass.

My personal impression is, that replacing the XMlRpcWriter should be 
supported. In other words, if you create a patch that

     a) makes the class XmlRpcWriter public and
     b) replaces all occurrences of

           new XmlWriter(buffer, encoding);

        with

           newXmlWriter(buffer, encoding);

and no other committer intervenes, then I'd be ready to accept that patch.


Jochen


Josef Bajada wrote:
> Hi Jochen,
> 
> I was trying to find a proper place to find an answer to a question I
> have but I cant seem to find the right place to ask it... so I thought
> maybe it would be possible to get an answer from one of the xml-rpc
> developers.
> 
> I have my own XML-RPC server using the Apache Jakarta xml-rpc
> implementation together with Jetty. I noticed that when I send a
> response with a java.lang.String object as part of the response
> hashtable the string is not wrapped into <string> </string> tags. I
> know that according to the XML-RPC spec if you omit the type it should
> be taken foregranted to be string. However, I think that the client I
> am interacting with is expecting a <string> tag just the same. Is
> there some way of making the jakarta xml-rpc include the <string> tag?
> 
> thanks and best regards,
> 
> Josef
> 

Re: XML-RPC Question

[Josef Bajada <jo...@gmail.com>]

Hi Jochen,

OK I understand your point of view.

I will look into what you had originally proposed and maybe commit
something along those lines then.

regards,
Josef

On 10/5/05, Jochen Wiedmann <jo...@gmail.com> wrote:
> Josef Bajada wrote:
>
> > Why do you see it as specific? Its just giving the user a choice
> > whether to include the <string> tag or not for a string response.
> > Given that it complies with the specification (and the specification
> > actually recommends using <string>, it just has an ending note saying
> > that if there is nothing than one can assume its a string), why should
> > the user have to override the XmlWriter to just achieve this
> > functionality?
>
> There are *many* more syntactical details, that the XML-RPC may wish to
> customize. Examples? May be, the base64 encoder should produce lines of
> 76 characters or less? May be, some strings should be trimmed? Whatever.
> Why should we prefer to implement a solution for just one specific
> detail and not a solution that allows others to ensure their specific
> wishes as well?
>
>
> Jochen
>

Re: XML-RPC Question

[Jochen Wiedmann <jo...@gmail.com>]

Josef Bajada wrote:

> Why do you see it as specific? Its just giving the user a choice
> whether to include the <string> tag or not for a string response.
> Given that it complies with the specification (and the specification
> actually recommends using <string>, it just has an ending note saying
> that if there is nothing than one can assume its a string), why should
> the user have to override the XmlWriter to just achieve this
> functionality?

There are *many* more syntactical details, that the XML-RPC may wish to 
customize. Examples? May be, the base64 encoder should produce lines of 
76 characters or less? May be, some strings should be trimmed? Whatever. 
Why should we prefer to implement a solution for just one specific 
detail and not a solution that allows others to ensure their specific 
wishes as well?


Jochen

Re: XML-RPC Question

[Josef Bajada <jo...@gmail.com>]

Hi Jochen,

Why do you see it as specific? Its just giving the user a choice
whether to include the <string> tag or not for a string response.
Given that it complies with the specification (and the specification
actually recommends using <string>, it just has an ending note saying
that if there is nothing than one can assume its a string), why should
the user have to override the XmlWriter to just achieve this
functionality?

best regards,
Josef


On 10/5/05, Jochen Wiedmann <jo...@gmail.com> wrote:
> Josef Bajada wrote:
>
> > I think you are referring to XmlWriter here not XmlRpcWriter, right?
>
> Yes, sorry!
>
>
> > If you think this might be useful for other users we can put it in. (I
> > would rather have it included as part of the xml-rpc codebase so that
> > I would be able to upgrade to future versions of xml-rpc without
> > effecting this feature.)
> >
> > What do you think?
>
> I believe that my proposed changes aren't much larger than yours,
> although your change is *very* specific and hardly required by anyone
> but you. So, unless another committer intervenes, I am not open to
> accept a patch forcing the "string" tag.
>
>
> Sorry,
>
> Jochen
>

Re: XML-RPC Question

[Jochen Wiedmann <jo...@gmail.com>]

Josef Bajada wrote:

> I think you are referring to XmlWriter here not XmlRpcWriter, right?

Yes, sorry!


> If you think this might be useful for other users we can put it in. (I
> would rather have it included as part of the xml-rpc codebase so that
> I would be able to upgrade to future versions of xml-rpc without
> effecting this feature.)
> 
> What do you think?

I believe that my proposed changes aren't much larger than yours, 
although your change is *very* specific and hardly required by anyone 
but you. So, unless another committer intervenes, I am not open to 
accept a patch forcing the "string" tag.


Sorry,

Jochen