The mailing list for listmasters using Sympa

[Olivier Salaün <address@concealed>]

Hi Catherine,

address@concealed a écrit :
> I'm currently working with Sympa 5.3.3 and the SOAP interface. 
>
> I have created my Java client code as directed on your page:
> http://www.sympa.org/manual/soap#web_server_setup
>
> using axis 1.4. I've then used the stubs to create a list. 
>
> I posted a request for help back in March regarding a Bad types exception, the
> java code, produced from the wsdl was expecting a boolean but the perl sub
> "createList" with sympasoap.pm returned 1, which Java interpreted as an int.
> Serge kindly suggested a fix which was just to change "createList" from 
> "return
> 1" to just "return", unfortunately this resulted in a null pointer error my
> java code. Eventually I settled for "return true". This has worked well up
> until now when I have been exploring the soap service
> authenticateRemoteAppAndRun.
>
> According to the WSDL this service must return an array of string. When I use
> this method using the "createList" service I was getting the SAXException:
> Found character data inside an array element while deserializing. This was
> because the createList service was just returning "true" which is a string not
> a string array. To overcome this I have had to change the sympasoap.pm sub
> createList to return the following:
> return SOAP::Data->name('result')->type('boolean')->value(1);
>
>   
You're right, this is the right way to return from the subroutine.
I've fixed just this in both our stable and development branches, thanks.
> this ensures that a standalone call to createList results in a valid response
> of type boolean as defined by the wsdl. 
> The down side of this now is that the return from authenticateRemoteAppAndRun
> still throws a SAXExceptionl. In order to overcome this I am now writing code
> within the sub authenticateRemoteAppAndRun to check what is being returned by
> the service being accessed from it and if it is something other than a string
> array I am altering it ensure it is returned as a string element within an
> array. For example with the boolean returned from createList I create a new
> SOAP:Data item of type string with a value of true and push this onto a new
> array object which gets successfully returned to my java code containing a
> value I can work with.
>
> Has anyone else come across issues such a this and am I missing something? If
> the service authenticateRemoteAppAndRun is supposed to work with all other
> services such as createList, review, closeList etc should it not be checking
> that the return types from these services are applicable to what
> authenticateRemoteAppAndRun is returning? I don't think java is quite a
> forgiving as perl.
>   
Thanks for reporting this problem : we're obviously consistent regarding 
SOAP return codes when using authenticateAndRun() and 
authenticateRemoteAppAndRun() SOAP functions. We did not notice the 
problem because, as you mentioned, Perl is forgiving about data types 
and we use Perl or Php SOAP clients ourselves.

I think it's worth explaining why we introduced authenticateAndRun() and 
authenticateRemoteAppAndRun() SOAP functions ; then we might find a 
technical solution to your problem.

1) The authenticateAndRun() function was first introduced to make Sympa 
work with SOAP client libraries that can't use HTTP cookies to maintain 
sessions on the client side ; nuSOAP PHP was the problematic SOAP 
library. The authenticateAndRun() allowed to perform both authentication 
+ any other SOAP operation in a single call. It had the benefit of 
requiring a single new SOAP function versus adding many new functions 
authenticateAndSubscribe(), authenticateAndDel(),... On the other hand 
we had a problem with incoming and outgoing parameters for this 
authenticateAndRun() function : ArrayOfString was quite adapted for the 
input but ArrayOfString might not be adapted for the output.

2) Later we introduced a way for a SOAP client application to 
authenticate (versus user authentication) against the Sympa SOAP server. 
This mutual trust needed new functions to authenticate and we decided to 
adopt the same schema as authenticateAndRun() with the new 
authenticateRemoteAppAndRun() SOAP function. But this lead to the same 
limitation regarding types of outgoing parameters.

Among possible solutions are :

   * polymorphism : I don't know if WSDL can provide some kind of
     polymorphism to have different kind of output types.
   * multiplication of SOAP functions
     (authenticateRemoteAddAndRunX,...) : I'm not in favour of this
     because maintaining both WSDL and code will be a burden
   * introduce some kind of SOAP sessionning so that your SOAP client
     can run authenticateRemoteApp() and then run createList()
   * find a trick a allow different kind of output types from
     authenticateRemoteAppAndRun()

We'd like some feedback from the SOAP gurus out there...