[MOBY-dev] Updates to MOBY Central andIMPORTANT NOTES forregistry hosts
Edward Kawas
edward.kawas at gmail.com
Tue Feb 6 17:49:13 UTC 2007
So something is wrong with the routine that is sending the async wsdl,
because there is nothing wrong with your script using category == moby.
I will track down the culprit and get back to you!
Eddie
-----Original Message-----
From: moby-dev-bounces at lists.open-bio.org
[mailto:moby-dev-bounces at lists.open-bio.org] On Behalf Of Romina Royo
Sent: Tuesday, February 06, 2007 9:10 AM
To: markw at illuminae.com; Core developer announcements
Subject: Re: [MOBY-dev] Updates to MOBY Central andIMPORTANT NOTES
forregistry hosts
Hello,
The retrieveService function of the Perl API still doesn't seem to work
for me (while using soap 0.69)... I get 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 1378.
ERROR ERROR ERROR
It works for 'moby' services but it does not work for 'moby-async' services.
Here's an exmple of the scripts I'm using:
------------------
#!/usr/bin/perl -w
use FindBin qw($Bin);
use lib "$Bin";
use MOBY::Client::Central;
use MOBY::Client::Service;
use MOBY::CommonSubs;
#use SOAP::Lite + trace;
use strict;
my $URL =
'http://mobycentral.icapture.ubc.ca/cgi-bin/MOBY05/mobycentral.pl';
my $URI = 'http://mobycentral.icapture.ubc.ca/MOBY/Central';
my $Central = MOBY::Client::Central->new(
Registries => {mobycentral => {URL => $URL,URI => $URI}});
my ($ServiceInstances, $RegObject) = $Central->findService(
serviceName=> 'runClustalwFast',
authURI => 'inb.bsc.es'
);
print "ServiceInstances? " . $ServiceInstances->[0]->name . "\n";
my $WSDL = $Central->retrieveService($ServiceInstances->[0]);
print "WSDL:::::::\n" . $WSDL . "\n";
-----------------
Thanks!
Romina
mark wilkinson wrote:
> Super! That's great news!
>
> So, does that mean that everything is OK?
>
> M
>
>
>
> --
> Mark Wilkinson
> ...on the road!
>
>
> -----Original Message-----
> From: Romina Royo <rroyo at lsi.upc.edu>
> Date: Tue, 06 Feb 2007 17:18:33
> 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 forregistry hosts
>
> Hello Mark,
>
> I used gbrowse to call one of our services:
>
> - first test we had .69 on the server side and as you said it worked ok
>
> - second test we had 0.60 on the server side and it also worked ok.
>
> I hope this is the test you were asking for :-)
>
> Thanks!
> Romina
>
>
> Mark Wilkinson wrote:
>
>> Hi Romina,
>>
>> I can confirm that calling services running S::L 0.69 from a client
>> running S::L 0.55 is succesful. .69 to .69 is obviously OK also. What I
>> have not yet successfully tested is calling a service from a .69 client
to
>> an earlier version on the server-side. The way to do that would be to
use
>> gbrowse_moby on the mobycentral machine, but I don't know what versions
of
>> Perl anyone else is running so I can't reliably do that experiment...
can
>> anyone try one of their Perl services from gbrowse-moby on a server with
>> perl 0.60 or less?
>>
>> MOBY Central itself seems fine... and Java invocations of services seem
>> fine also (largely because the Java libraries don't use the WSDL from
MOBY
>> Central to create their connections... there may be a lesson in there
>> somewhere! Ugh... WSDL!!)
>>
>> M
>>
>>
>>
>>
>> On Tue, 06 Feb 2007 07:38:59 -0800, Romina Royo <rroyo at lsi.upc.edu>
wrote:
>>
>>
>>
>>> 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
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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
>
_______________________________________________
MOBY-dev mailing list
MOBY-dev at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/moby-dev
More information about the MOBY-dev
mailing list