[MOBY-dev] Updates to MOBY Central and IMPORTANT NOTES forregistry hosts

Tue Feb 6 15:38:59 UTC 2007

Hello again,

Mark, I just called your service and it did work.

Eddy, if those are some of the errors you fixed yesterday I might be 
doing something wrong. Let me re-check everything and if the errors are 
still there I'll send you more details about the code I'm using.

Thank you very much!
Romina

mark wilkinson wrote:
> Hmmmm... Well that's a bit of a disaster!  
>
> Could you check what happens when you call one of my services (eg MOBYSHoundGetGenbankff)?  I wonder if SOAP::Lite versions don't talk to each other properly (which would be a nightmare, but given our experiences yesterday, not surprising!)
>
> M
>
>
> --
> Mark Wilkinson
> ...on the road!
>
>
> -----Original Message-----
> From: Romina Royo <rroyo at lsi.upc.edu>
> Date: Tue, 06 Feb 2007 15:25:15 
> To:Core developer announcements <moby-dev at lists.open-bio.org>
> Cc:mobydev <moby-dev at biomoby.org>
> Subject: Re: [MOBY-dev] Updates to MOBY Central and IMPORTANT NOTES for
>  registry hosts
>
> Hello,
>
> I updated the moby-live/Perl libraries from cvs and I installed 
> SOAP::Lite 0.69.
>
> Here are some of the results I got:
>
> - When executing a synchronous Perl service (function execute in 
> Client/Service.pm) I got this error:
>
> <SOAP-ENV:Fault><faultcode>SOAP-ENV:VersionMismatch</faultcode><faultstring>Wrong 
> SOAP version specified. Supported versions:
>   1.1 (http://schemas.xmlsoap.org/soap/envelope/)
>   1.2 (http://www.w3.org/2001/06/soap-envelope)
> </faultstring></SOAP-ENV:Fault>
>
> mm.. I guess it is OK because the service provider might be using some 
> other SOAP version?
>
> - When doing the same test on one of our services (SOAP::Lite 0.69 
> installed on the service side). I got this error:
>
> <soap:Fault><faultcode>soap:Client</faultcode><faultstring>Application 
> failed during request deserialization:
> xml declaration not at start of external entity at line 1, column 941, 
> byte 941 at 
> /usr/lib/perl5/site_perl/5.8.3/x86_64-linux-thread-multi/XML/Parser.pm 
> line 187
> </faultstring></soap:Fault>
>
> - When executing a Java service:
>   <soapenv:Fault>
>    <faultcode>soapenv:Client</faultcode>
>    <faultstring>org.jboss.axis.AxisFault: Version Mismatch</faultstring>
>    <detail/>
>   </soapenv:Fault>
>
> and again, it might be ok?
>
> - When trying to retrieve the wsdl of a 'moby-async' service (function 
> retrieveService) I got this error:
>
> Connection to MOBY Central at 
> 'http://mobycentral.icapture.ubc.ca/MOBY/Central'
> died because:
>         Can't use string ("<?xml version="1.0"?>
>         <definiti") as a symbol ref while "strict refs" in use at 
> /usr/lib/perl5
> /site_perl/5.8.5/MOBY/Central.pm line 3290, <IN> line 371.
>
>  ERROR ERROR ERROR
>
> The function retrieveService does work when the service is not 
> 'moby-async' though.
>
> - When executing an asynchronous service (function 
> Async/Service/execute) everything seems ok.
>
> Has anyone had similar problems? Any ideas?
>
> Thank you!
> Romina
>
> Mark Wilkinson wrote:
>   
>> Hi all,
>>
>> First off, apologies to anyone who was trying to get through to MOBY  
>> Central this afternoon - Eddie and I were making the changes necessary to  
>> get it ready for SOAP::Lite 0.69 and the changes that worked perfectly on  
>> the test server didn't work on the real MOBY Central... so it took a  
>> couple of hours of troubleshooting before we had it back up again.
>>
>> The good news is that it seems to work correctly with both Perl and Java  
>> clients.  What we don't know is if it is backwards compatible with earlier  
>> versions of the MOBY::Client::* libraries, in particular,  
>> MOBY::Client::Service.  I *think* it is, but we didn't have the  
>> opportunity to test it.  In any case, the API did not change, so if you  
>> just cvs update your client libraries everything should come back to life  
>> if it isn't working.
>>
>> Upgrading to SOAP::Lite 0.69 was a nightmare!  The new SOAP::Lite behaves  
>> subtly differently than the old one in several ways that we were not  
>> expecting.  Thankfully, Pieter and Eddie had done most of the  
>> trouble-shoting already, but it still threw us for a loop in some places  
>> with incompatible SOAP version errors and a new auto-encoding of strings  
>> by SOAP::Lite that we used to do in-code by ourselves (resulting in  
>> double-coded messages).
>>
>> Anyway, it's done now.  Please scream loudly if it doesn't work for you!!   
>> I have backups of everything so if necessary we can roll-back quickly.
>>
>> All of this was done primarily to get us to be compatible with the new  
>> Asynchronous services API that use the Manchester WSRF::Lite modules which  
>> depend on SOAP::Lite 0.69.  Can I ask the good folks at INB to test the  
>> code to see if it works for them v.v. Async services?  The database can  
>> now hold Category=moby-async (which reminds me, I need to update the  
>> database templates in the CVS...), and Eddie assures me that the code will  
>> now provide correct WSDL for an Asych interface.  The myGrid folks have  
>> added moby-async as a valid service category into their ontology as well,  
>> so in principle... it should all work... (touch wood!)
>>
>> *********************
>> IMPORTANTLY this means that the new MOBY Central code will likely NOT work  
>> on versions of SOAP::Lite prior to 0.69!!!  Keep this in mind if you are  
>> running your own registry...
>> *********************
>>
>> Tomorrow (if I have regained my sanity after todays hell ;-) ) I'll try to  
>> make the changes to gbrowse_moby such that it can also invoke asynchronous  
>> services.  I think the Async modules also need to be added to the MANIFEST  
>> before they are installed by default, so I'll try to remember to do that  
>> as well.
>>
>> Otherwise there were just some small changes to the test suite to better  
>> clean-up the registry if something goes wrong during testing, and I  
>> cleaned-up the test database so that it also doesn't cause the test suite  
>> to fail.  I will restart the test registry using the new codebase first  
>> thing in the morning so that the two are identical.
>>
>> We still haven't figured out why those namespace changes happened a couple  
>> of days ago.  It coincided with the Gene Ontology curators making some  
>> additions to the Namespace list, so I suspect that there is a bug in the  
>> interface I have given to them (which talks directly to the database  
>> without using the MOBY API), but exactly WHY this happened is still a  
>> mystery.  I've alerted Midori to the problem and she's going to hold-off  
>> on making any more changes until we can figure out what is going wrong.
>>
>> That's all the news from MOBY Central!
>>
>> Let us know ASAP if you notice anything wrong.  It's been a rough ride  
>> today...
>>
>> Mark
>>
>>
>>
>> _______________________________________________
>> MOBY-dev mailing list
>> MOBY-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/moby-dev
>>   
>>     
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/moby-dev
>   