From wong.yan at netcourrier.com Thu Dec 2 11:39:56 2004 From: wong.yan at netcourrier.com (wong.yan@netcourrier.com) Date: Thu Dec 2 05:37:31 2004 Subject: [MOBY-dev] question about the bioMoby python API Message-ID: one other solution is to put a type attribute on the body tag: the CORRECT message should be: your MobyContent in XML ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) From mark.fiers at wur.nl Thu Dec 2 08:19:59 2004 From: mark.fiers at wur.nl (Mark Fiers) Date: Thu Dec 2 07:23:03 2004 Subject: [MOBY-dev] question about the bioMoby python API In-Reply-To: References: Message-ID: <41AF167F.10001@wur.nl> wong.yan@netcourrier.com wrote: >one other solution is to put a type attribute on the body tag: > > But, if i am not mistaking, that would then have to be done by the people running http://mobycentral.cbr.nrc.ca/cgi-bin/gbrowse_moby since this site generates the ?'faulty'? body tag. (is it faulty? or is it still a valid soap call? Would a workaround be to edit the zsi code to default to a string if it doesn't find a xsi:type attribute? Or would that cause different problems? Mark >the CORRECT message should be: >your MobyContent in XML > > >------------------------------------------------------------- >NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... >Web/Wap : www.netcourrier.com >T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) >Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From wong.yan at netcourrier.com Thu Dec 2 21:13:47 2004 From: wong.yan at netcourrier.com (wong.yan@netcourrier.com) Date: Thu Dec 2 15:11:21 2004 Subject: [MOBY-dev] question about the bioMoby python API Message-ID: at my level, I believe it is an error, because the tag represent an object with a string inside (so what's the use of the body tag??). However, the SOAP call is still valid (so I work on a workaround for it). A work around on the ZSI patch will surely solve this issue, I am working it but at little speed... look at the file ZSI-1.5.0-patched/ZSI/TC.py: at the line: 254: if len(_child_elements(elt)) == 0: raise EvaluateException("Any cannot parse untyped element", ps.Backtrace(elt)) maybe a "return elt" (elt as a string) instead of "raise Exception etc.." should be sufficient... however, the Body is followed by the <[CDATA tag, this tag should be dropped in order to treat the MobyContent There may be another solution, define a class call Body but ZSI, the technique is described in the ZSI documentation page but the example with the "from ZSI import Path" doesn't work as the Path file is inexistant and make the script fail. link to the documentation of ZSI http://pywebsvcs.sourceforge.net/zsi.html see chapter 2.2.2 for defining a class for ZSI. ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) From mwilkinson at mobile.rogers.com Fri Dec 3 08:57:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri Dec 3 08:55:49 2004 Subject: [MOBY-dev] Test request Message-ID: <200412031355.iB3DtlKr006219@portal.open-bio.org> Hi everyone, Can a few of you test mobycentral to see if it works for you? It is working for me (in my hotel room), but not for Rebecca nor Martin... I'm wondering if it is the connection between europe and here? M !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Fri Dec 3 13:05:14 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri Dec 3 13:04:10 2004 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031804.iB3I47Kr008138@portal.open-bio.org> I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) Can our European partners keep an eye on it and let me know when it comes back up? Thanks! M !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From beatrice at arabidopsis.info Fri Dec 3 13:16:21 2004 From: beatrice at arabidopsis.info (Beatrice Schildknecht) Date: Fri Dec 3 13:15:07 2004 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> References: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: <41B0AD75.3060400@arabidopsis.info> I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From beatrice at arabidopsis.info Fri Dec 3 13:16:21 2004 From: beatrice at arabidopsis.info (Beatrice Schildknecht) Date: Fri Dec 3 13:15:09 2004 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> References: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: <41B0AD75.3060400@arabidopsis.info> I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From mwilkinson at mobile.rogers.com Fri Dec 3 13:18:54 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri Dec 3 13:18:48 2004 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031818.iB3IIkKr008258@portal.open-bio.org> Ha! So Beatrice does live on! You should have stayed silent - now I will chase you down to fix your broken services ;-) M -----Original Message----- From: Beatrice Schildknecht Date: Fri, 03 Dec 2004 18:16:21 To:mwilkinson , Core developer announcements Cc:Moby-dev@open-bio.org Subject: Re: [MOBY-dev] It appears to be a European problem... I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Fri Dec 3 13:18:54 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri Dec 3 13:18:49 2004 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031818.iB3IIlKr008262@portal.open-bio.org> Ha! So Beatrice does live on! You should have stayed silent - now I will chase you down to fix your broken services ;-) M -----Original Message----- From: Beatrice Schildknecht Date: Fri, 03 Dec 2004 18:16:21 To:mwilkinson , Core developer announcements Cc:Moby-dev@open-bio.org Subject: Re: [MOBY-dev] It appears to be a European problem... I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Fri Dec 3 13:45:16 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Fri Dec 3 13:43:27 2004 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: > Can our European partners keep an eye on it and let me know when it comes back up? > Well, England is back in the bussiness: [senger@localhost jMoby]$ build/run/run-testing-central retrieveServiceNames OK retrieveServiceProviders OK retrieveServiceTypes OK retrieveNamespaces OK retrieveObjectNames OK registerServiceType OK registerNamespace - 1 OK registerNamespace - 2 OK registerDataType - 1 OK registerDataType - 3 OK registerDataType - 2 OK getDataTypeDefinition - 2 OK registerService OK deregisterService OK deregisterDataType - 2 OK deregisterDataType - 3 OK deregisterDataType - 1 OK deregisterNamespace - 2 OK deregisterNamespace - 1 OK deregisterServiceType OK Thanks, Martin -- Martin Senger EMBL Outstation - Hinxton Senger@EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From duncan.hull at cs.man.ac.uk Tue Dec 7 04:11:59 2004 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Tue Dec 7 04:09:33 2004 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: References: Message-ID: <41B573DF.50501@cs.man.ac.uk> Martin Senger wrote: > Well, England is back in the bussiness: > >[senger@localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From d.haase at gsf.de Tue Dec 7 04:43:16 2004 From: d.haase at gsf.de (Dirk Haase) Date: Tue Dec 7 04:40:30 2004 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <41B573DF.50501@cs.man.ac.uk> References: <41B573DF.50501@cs.man.ac.uk> Message-ID: <200412071043.16612.d.haase@gsf.de> On Tuesday 07 December 2004 10:11, Duncan Hull wrote: > Martin Senger wrote: > > Well, England is back in the bussiness: > > > >[senger@localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, > which was working fine last night. Does anyone else in Europe have the > same problem? Yep, Germany is locked out as well. It went somehow in the early morning (~8am MET), but veeeeryyyy slow... Now it's completely gone :-( dirk From m.rouard at cgiar.org Tue Dec 7 04:56:15 2004 From: m.rouard at cgiar.org (Rouard, Mathieu (INIBAP - Montpellier)) Date: Tue Dec 7 04:52:03 2004 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <31AB896A0E7ED211BFBE0008C7283D13F936B3@inibapnt1.inibap.org> Hi Duncan, I have also some trouble in france today . I cannot connect to mobycentral. regards, mathieu -- Mathieu Rouard IPGRI-INIBAP < www.inibap.org > Parc Scientifique Agropolis II 34397 Montpellier - Cedex 5 - France Tel: +33 (0)467 61 13 02 Fax: +33 (0)467 61 03 34 -----Original Message----- From: Duncan Hull [mailto:duncan.hull@cs.man.ac.uk] Sent: mardi 7 d?cembre 2004 10:12 Cc: Moby-dev@open-bio.org; Mark Wilkinson Subject: Re: [MOBY-dev] It appears to be a European problem... Martin Senger wrote: > Well, England is back in the bussiness: > >[senger@localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From m.rouard at cgiar.org Tue Dec 7 04:56:15 2004 From: m.rouard at cgiar.org (Rouard, Mathieu (INIBAP - Montpellier)) Date: Tue Dec 7 04:52:04 2004 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <31AB896A0E7ED211BFBE0008C7283D13F936B3@inibapnt1.inibap.org> Hi Duncan, I have also some trouble in france today . I cannot connect to mobycentral. regards, mathieu -- Mathieu Rouard IPGRI-INIBAP < www.inibap.org > Parc Scientifique Agropolis II 34397 Montpellier - Cedex 5 - France Tel: +33 (0)467 61 13 02 Fax: +33 (0)467 61 03 34 -----Original Message----- From: Duncan Hull [mailto:duncan.hull@cs.man.ac.uk] Sent: mardi 7 d?cembre 2004 10:12 Cc: Moby-dev@open-bio.org; Mark Wilkinson Subject: Re: [MOBY-dev] It appears to be a European problem... Martin Senger wrote: > Well, England is back in the bussiness: > >[senger@localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Dec 7 04:56:02 2004 From: d.haase at gsf.de (Dirk Haase) Date: Tue Dec 7 04:53:15 2004 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412071043.16612.d.haase@gsf.de> References: <41B573DF.50501@cs.man.ac.uk> <200412071043.16612.d.haase@gsf.de> Message-ID: <200412071056.02072.d.haase@gsf.de> On Tuesday 07 December 2004 10:43, Dirk Haase wrote: > On Tuesday 07 December 2004 10:11, Duncan Hull wrote: > > Martin Senger wrote: > > > Well, England is back in the bussiness: > > > > > >[senger@localhost jMoby]$ build/run/run-testing-central > > > > I'm having trouble running mobycentral from Martins latest jMoby client, > > which was working fine last night. Does anyone else in Europe have the > > same problem? > > Yep, Germany is locked out as well. It went somehow in the early morning > (~8am MET), but veeeeryyyy slow... Now it's completely gone :-( ... and _now_ it's ok again. Thanks to whoever... From mwilkinson at mrl.ubc.ca Tue Dec 7 12:21:02 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Dec 7 11:52:58 2004 Subject: [MOBY-dev] [Fwd: [personal] Re: Intermittent loss of MOBY from Europe] Message-ID: <1102440061.16721.22.camel@mobycentral.icapture.ubc.ca> Hi all, Since your reports are generally coming in while I am sleeping and the problem is fixed by the time I wake up, can I ask you to do these tests next time you find that you cannot connect to MOBY Central? It's happened a few times in the past two weeks, and I'd like to know what the source of the problem is. thanks! M > Hi Mark, > > All of our tests show that the Moby service is reachable via Europe. > Next time you suspect connectivity problems, please go to: > > www.traceroute.org > > and try a few tests from the various links in Europe to see where the > problem lies. Then, if you can send us the output from your tests, we > should be able to determine if the problem lies in our network or > externally. Most of the links on this site have options to traceroute to > an IP (others have ping and other services available). -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From ywong at infobiogen.fr Wed Dec 8 11:17:22 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Wed Dec 8 11:14:47 2004 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: <41B72912.6030702@infobiogen.fr> I've solved the problem and posted corrections to the CVS. See changelog for listed modifications. Here are the following steps to do to update your bioMoby Python server API: In your bioMoby python package directory: -First update your ZSI library with the ZSI library provided by this package: cd packages tar jxvf ZSI-1.5.0-patched-2 cd ZSI-1.5.0-patched-2 python setup.py install (with your fancy options if you have) -Update your bioMoby Python library python setup.py install (with options) -Update your scripts by applying the rules: however, you'll have to change some things in your script: BEFORE: from ZSI import dispatch dispatch.AsCGI() NOW: from ZSI import dispatch from bioMoby.webservice import TCBioMoby dispatch.AsCGI(typesmodule=TCBioMoby) or with mod_python: dispatch.AsHandler(modules=myModule,), request=req, typesmodule=TCBioMoby) TCBioMoby contains a class that serialize/deserialize the content inside the tag Body into a MobyContent Object. This will allow a Python webservice to deal with gbrowse_moby. From mwilkinson at mrl.ubc.ca Wed Dec 8 11:54:01 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Dec 8 11:25:35 2004 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > This will allow a Python webservice to deal with gbrowse_moby. Does gbrowse_moby send incorrectly formatted messages? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Wed Dec 8 11:54:01 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed Dec 8 11:25:36 2004 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > This will allow a Python webservice to deal with gbrowse_moby. Does gbrowse_moby send incorrectly formatted messages? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From ywong at infobiogen.fr Wed Dec 8 12:05:53 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Wed Dec 8 12:03:16 2004 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: <41B72912.6030702@infobiogen.fr> <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> Message-ID: <41B73471.8020701@infobiogen.fr> AFAIK no, it doesn't. It is just a matter of mapping between XML objects and Python objects. As I have never used gbrowse_moby to test my services, I didn't know the MobyContent object was included in a body tag. My soap call send the MobyContent inside a string object: MobyContent Mark Wilkinson wrote: >On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > > > > >>This will allow a Python webservice to deal with gbrowse_moby. >> >> > > >Does gbrowse_moby send incorrectly formatted messages? > >M > > > > From mark.fiers at wur.nl Fri Dec 10 09:29:27 2004 From: mark.fiers at wur.nl (Mark Fiers) Date: Fri Dec 10 08:32:16 2004 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <41B9B2C7.6090901@wur.nl> Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From paulien.adamse at wur.nl Fri Dec 10 10:13:52 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Fri Dec 10 10:11:27 2004 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: Now the Python API has been fixed I get some results with my service. Great! But the output is not what it should be. Anybody got an idea what is wrong with it? At the moment the "content" also contains the result, but it should be visible for Namespace and Id as well. The function is called getWAtDBIdByPOAcc The function can be called with namespace PO_acc id 9054 I could realy use some feedback. Thanks in advance (and have a nice weekend...) Paulien Adamse -----Original Message----- From: moby-dev-bounces@portal.open-bio.org [mailto:moby-dev-bounces@portal.open-bio.org] On Behalf Of Fiers, Mark Sent: vrijdag 10 december 2004 15:29 To: Core developer announcements Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From paulien.adamse at wur.nl Fri Dec 10 10:17:26 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Fri Dec 10 10:16:17 2004 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: -----Original Message----- From: Adamse, Paulien Sent: vrijdag 10 december 2004 16:14 To: 'Core developer announcements' Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Now the Python API has been fixed I get some results with my service. Great! But the output is not what it should be. Anybody got an idea what is wrong with it? At the moment the "content" also contains the result, but it should be visible for Namespace and Id as well. The function is called getWAtDBIdByPOAcc The function can be called with namespace PO_acc id 9054 I could realy use some feedback. Thanks in advance (and have a nice weekend...) Paulien Adamse -----Original Message----- From: moby-dev-bounces@portal.open-bio.org [mailto:moby-dev-bounces@portal.open-bio.org] On Behalf Of Fiers, Mark Sent: vrijdag 10 december 2004 15:29 To: Core developer announcements Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Sat Dec 11 12:38:57 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Sat Dec 11 12:36:16 2004 Subject: [MOBY-dev] A few new tools and updates Message-ID: <41BB30B1.8040105@illuminae.com> Hi all, Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: 1) Eddie has finished writing applets that help in the construction of new tools for creating objects,service types, and registering new service instances. Try them at: http://mobycentral.cbr.nrc.ca/applets (note that this is operating on the "live" database) 2) For a variety of reasons we've decided to change the structure of the Service Instance RDF. As such, I have temporarily switched the deregisterService function back 'on' in MOBY Central. You can deregister services as before using the API. 3) Once we have a good RDF generator, we will ask you again to retrieve the RDF of your services and we'll switch Nina's agent on. I'll then switch the deregisterService function 'off' again. Cheers all! Mark P.S. I'm planning to host the next (possibly last, depending on funding...) MOBY developers meeting in Vancouver in early May, 2005. Does anyone know of other conferences going on that we should avoid conflicting with? From ywong at infobiogen.fr Mon Dec 13 04:43:46 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon Dec 13 04:41:04 2004 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: Message-ID: <41BD6452.7090105@infobiogen.fr> You should have: -Output query name should be the same as Input query name: (Input : I have 'query1' as name for the query and I get '9054'?) -You seems to send a collection of identifiers, so you should return a collection of objects. With the Python API, just put your set of objects in a tuple: ('collectionName' , [object1, object2, object3, etc..]) the mobyContent will serialize the collection into this: -you return an object with namespace=WatDB inside the content. maybe is it better to put it in a cross reference: o=MobyObject(namespace='PO_acc', id='118') o._cross=[MobyObject(namespace='WatDB', id='118'] ( don' forget the [] because it is a set of objects) or use the MobyXref object to build a Xref object (defined in the Moby-s v0.8 API) from bioMoby import MobyXref xref=MobyXref("EMBL","X1112345", "www.illuminae.com","getEMBLRecord", "IEA", transform") see help(MobyXref) for details. or you want to return an object with WatDB namespace and id: o=MobyObject(namespace='WatDB', id='118') In all case, you must register WatDB as a namespace in the bioMoby directory: >>> from bioMoby import Namespace >>> watdb=Namespace(namespaceType="WatDB", contact="contact@host.domain", authURI="host.domain", description=" a small description of this object") If you want to register on another central than bioMoby: >>> from bioMoby import Central >>> newCentral=Central(url="URL_of_another_bioMoby_directory", ns="http://another_namespace") (see help(Central) for the other instanciation parameters) >>> watdb.central=newCentral and then register your new object: >>> result=watdb.register() and see if it is successful: >>> print result Adamse, Paulien wrote: >-----Original Message----- >From: Adamse, Paulien >Sent: vrijdag 10 december 2004 16:14 >To: 'Core developer announcements' >Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Now the Python API has been fixed I get some results with my service. >Great! But the output is not what it should be. Anybody got an idea what >is wrong with it? At the moment the "content" also contains the result, >but it should be visible for Namespace and Id as well. > >The function is called getWAtDBIdByPOAcc >The function can be called with namespace PO_acc id 9054 > >I could realy use some feedback. > >Thanks in advance >(and have a nice weekend...) > > >Paulien Adamse > >-----Original Message----- >From: moby-dev-bounces@portal.open-bio.org >[mailto:moby-dev-bounces@portal.open-bio.org] On Behalf Of Fiers, Mark >Sent: vrijdag 10 december 2004 15:29 >To: Core developer announcements >Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Thank you very much!!!!! > >It almost works. I had to make one small change (after some searching); >The Body class you've written is identified by a getattr in the module >in question. This does not work since the tag send by >gbrowse_moby is in lowercase. I've worked aroud this by changing 'class >Body:' to 'class body:'. (is it possible to define __getattr__() on >module level??? That would be a nice way to circumvent this problem) > >Concerning Mark's question if gbrowse_moby sends incorrectly formatted >messages? The tag is as far as I understand not a valid soap tag >and apparantly also not part of bioMoby XML. So, I would say that it is >still open for discussion, I'm not an expert on the subject. > >Cheers >Mark > > > > >Yan Wong wrote: > > > >>I've solved the problem and posted corrections to the CVS. >> >>See changelog for listed modifications. >> >>Here are the following steps to do to update your bioMoby Python >>server API: >> >>In your bioMoby python package directory: >> >>-First update your ZSI library with the ZSI library provided by this >>package: >>cd packages >>tar jxvf ZSI-1.5.0-patched-2 >>cd ZSI-1.5.0-patched-2 >>python setup.py install (with your fancy options if you have) >> >>-Update your bioMoby Python library >>python setup.py install (with options) >> >>-Update your scripts by applying the rules: >>however, you'll have to change some things in your script: >> >>BEFORE: >> >>from ZSI import dispatch >>dispatch.AsCGI() >> >>NOW: >> >>from ZSI import dispatch >>from bioMoby.webservice import TCBioMoby >> >>dispatch.AsCGI(typesmodule=TCBioMoby) >> >>or with mod_python: >> >>dispatch.AsHandler(modules=myModule,), request=req, >>typesmodule=TCBioMoby) >> >>TCBioMoby contains a class that serialize/deserialize the content >>inside the tag Body into a MobyContent Object. >> >>This will allow a Python webservice to deal with gbrowse_moby. >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From ywong at infobiogen.fr Mon Dec 13 04:56:45 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon Dec 13 04:54:03 2004 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: <41B72912.6030702@infobiogen.fr> <41B9B2C7.6090901@wur.nl> Message-ID: <41BD675D.9000405@infobiogen.fr> The best way maybe it is to add another class in the TCBioMoby file: class body(Body): pass but then when you return the MobyContent to the client you should add: from bioMoby.webservice import TCBioMoby mobyContentToBeReturned=MobyContent(ResultsOfTheTreatments) mobyContentToBeReturned.typecode=TCBioMoby.body() #tell how ZSI should serialize mobyContentToBeReturned return mc Mark Fiers wrote: > Thank you very much!!!!! > > It almost works. I had to make one small change (after some > searching); The Body class you've written is identified by a getattr > in the module in question. This does not work since the tag > send by gbrowse_moby is in lowercase. I've worked aroud this by > changing 'class Body:' to 'class body:'. (is it possible to define > __getattr__() on module level??? That would be a nice way to > circumvent this problem) > > Concerning Mark's question if gbrowse_moby sends incorrectly formatted > messages? The tag is as far as I understand not a valid soap > tag and apparantly also not part of bioMoby XML. So, I would say that > it is still open for discussion, I'm not an expert on the subject. > > Cheers > Mark > > > > > Yan Wong wrote: > >> >> I've solved the problem and posted corrections to the CVS. >> >> See changelog for listed modifications. >> >> Here are the following steps to do to update your bioMoby Python >> server API: >> >> In your bioMoby python package directory: >> >> -First update your ZSI library with the ZSI library provided by this >> package: >> cd packages >> tar jxvf ZSI-1.5.0-patched-2 >> cd ZSI-1.5.0-patched-2 >> python setup.py install (with your fancy options if you have) >> >> -Update your bioMoby Python library >> python setup.py install (with options) >> >> -Update your scripts by applying the rules: >> however, you'll have to change some things in your script: >> >> BEFORE: >> >> from ZSI import dispatch >> dispatch.AsCGI() >> >> NOW: >> >> from ZSI import dispatch >> from bioMoby.webservice import TCBioMoby >> >> dispatch.AsCGI(typesmodule=TCBioMoby) >> >> or with mod_python: >> >> dispatch.AsHandler(modules=myModule,), request=req, >> typesmodule=TCBioMoby) >> >> TCBioMoby contains a class that serialize/deserialize the content >> inside the tag Body into a MobyContent Object. >> >> This will allow a Python webservice to deal with gbrowse_moby. >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev@biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From ywong at infobiogen.fr Mon Dec 13 08:43:46 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon Dec 13 08:41:01 2004 Subject: [MOBY-dev] register recursive types Message-ID: <41BD9C92.6000108@infobiogen.fr> Is it possible to register recursive types in a bioMoby directory? I tried this: 1: AbstactNode ISA Object Nodelist ISA Object HAS AbstractNode Node ISA AbstractNode HASA NodeList are there other solutions? From rebecca.ernst at gsf.de Mon Dec 13 11:20:27 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon Dec 13 12:18:35 2004 Subject: [MOBY-dev] registration of services not possible yet In-Reply-To: <41BB30B1.8040105@illuminae.com> References: <41BB30B1.8040105@illuminae.com> Message-ID: <41BDC14B.1020804@gsf.de> Hi Mark! I just tried to deregister/register my services - it still tells me that I am not allowed to deregister a service that is registered having a RDF!! Rebecca Mark Wilkinson wrote: > Hi all, > > Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: > > 1) Eddie has finished writing applets that help in the construction > of new tools for creating objects,service types, and registering new > service instances. Try them at: > http://mobycentral.cbr.nrc.ca/applets (note that this is operating on > the "live" database) > > 2) For a variety of reasons we've decided to change the structure of > the Service Instance RDF. As such, I have temporarily switched the > deregisterService function back 'on' in MOBY Central. You can > deregister services as before using the API. > > 3) Once we have a good RDF generator, we will ask you again to > retrieve the RDF of your services and we'll switch Nina's agent on. > I'll then switch the deregisterService function 'off' again. > > Cheers all! > Mark > > P.S. I'm planning to host the next (possibly last, depending on > funding...) MOBY developers meeting in Vancouver in early May, 2005. > Does anyone know of other conferences going on that we should avoid > conflicting with? > _______________________________________________ > moby-l mailing list > moby-l@biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From mwilkinson at mrl.ubc.ca Mon Dec 13 12:53:21 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon Dec 13 12:24:44 2004 Subject: [MOBY-dev] Re: [moby] [MOBY-l] registration of services not possible yet In-Reply-To: <41BDC14B.1020804@gsf.de> References: <41BB30B1.8040105@illuminae.com> <41BDC14B.1020804@gsf.de> Message-ID: <1102960400.30331.26.camel@mobycentral.icapture.ubc.ca> Doh! I forgot to restart the server. Try now... M On Mon, 2004-12-13 at 08:20, Rebecca Ernst wrote: > Hi Mark! > > I just tried to deregister/register my services - it still tells me that > I am not allowed to deregister a service that is registered having a RDF!! > > Rebecca > > > > > Mark Wilkinson wrote: > > > Hi all, > > > > Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: > > > > 1) Eddie has finished writing applets that help in the construction > > of new tools for creating objects,service types, and registering new > > service instances. Try them at: > > http://mobycentral.cbr.nrc.ca/applets (note that this is operating on > > the "live" database) > > > > 2) For a variety of reasons we've decided to change the structure of > > the Service Instance RDF. As such, I have temporarily switched the > > deregisterService function back 'on' in MOBY Central. You can > > deregister services as before using the API. > > > > 3) Once we have a good RDF generator, we will ask you again to > > retrieve the RDF of your services and we'll switch Nina's agent on. > > I'll then switch the deregisterService function 'off' again. > > > > Cheers all! > > Mark > > > > P.S. I'm planning to host the next (possibly last, depending on > > funding...) MOBY developers meeting in Vancouver in early May, 2005. > > Does anyone know of other conferences going on that we should avoid > > conflicting with? > > _______________________________________________ > > moby-l mailing list > > moby-l@biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Mon Dec 13 13:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon Dec 13 12:34:00 2004 Subject: [moby] [MOBY-dev] register recursive types In-Reply-To: <41BD9C92.6000108@infobiogen.fr> References: <41BD9C92.6000108@infobiogen.fr> Message-ID: <1102961020.30331.38.camel@mobycentral.icapture.ubc.ca> I'm not quite sure what you are trying to achieve in that set of objects...?? M On Mon, 2004-12-13 at 05:43, Yan Wong wrote: > Is it possible to register recursive types in a bioMoby directory? > > I tried this: > > 1: > AbstactNode ISA Object > > Nodelist ISA Object HAS AbstractNode > > Node ISA AbstractNode HASA NodeList > > are there other solutions? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Mon Dec 13 13:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon Dec 13 12:34:01 2004 Subject: [moby] [MOBY-dev] register recursive types In-Reply-To: <41BD9C92.6000108@infobiogen.fr> References: <41BD9C92.6000108@infobiogen.fr> Message-ID: <1102961020.30331.38.camel@mobycentral.icapture.ubc.ca> I'm not quite sure what you are trying to achieve in that set of objects...?? M On Mon, 2004-12-13 at 05:43, Yan Wong wrote: > Is it possible to register recursive types in a bioMoby directory? > > I tried this: > > 1: > AbstactNode ISA Object > > Nodelist ISA Object HAS AbstractNode > > Node ISA AbstractNode HASA NodeList > > are there other solutions? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From rebecca.ernst at gsf.de Tue Dec 14 04:01:37 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Tue Dec 14 05:43:49 2004 Subject: [MOBY-dev] service deregistration Message-ID: <41BEABF1.4050902@gsf.de> Hi Mark! the server restart didn't solve the problem. I still can only deregister services which are registered without RDF. Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst@gsf.de From mwilkinson at mrl.ubc.ca Tue Dec 14 11:37:44 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Dec 14 11:07:55 2004 Subject: [MOBY-dev] Re: [moby] [MOBY-l] service deregistration In-Reply-To: <41BEABF1.4050902@gsf.de> References: <41BEABF1.4050902@gsf.de> Message-ID: <1103042264.32326.34.camel@mobycentral.icapture.ubc.ca> Doh! DOH! You're right. The MOBY Central code is currently broken. Eddie is going to troubleshoot, and hopefully we'll have it up by the end of the day. In the meantime, MOBY Central is running on an older codebase, so almost everything is functioning properly. I'll restart the server again when the problem is identified. Sorry! M On Tue, 2004-12-14 at 01:01, Rebecca Ernst wrote: > Hi Mark! > > the server restart didn't solve the problem. I still can only deregister > services which are registered without RDF. > > Rebecca -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Tue Dec 14 19:45:52 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue Dec 14 19:15:55 2004 Subject: [MOBY-dev] For those who wanted tomcat on MOBY Central Message-ID: <1103071552.591.63.camel@mobycentral.icapture.ubc.ca> Hi all, I've had a few requests for a Tomcat installation on MOBY Central to deploy a variety of things there. Can I just check with those who have requested this whether you need Tomcat to be running through apache, or simply using its standalone server? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From paulien.adamse at wur.nl Wed Dec 15 02:49:30 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Wed Dec 15 02:46:50 2004 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: Hi Yan Wong, Thanks for your detailed response. It should be possible to make it work now! Paulien PS I already registered the namespace WAtDB_Id. And put it in the content just to see some output. Don't intend to keep showing it there. Paulien Adamse Applied Bioinformatics Kamer 0.210 Tel. (4)76850 -----Original Message----- From: moby-dev-bounces@portal.open-bio.org [mailto:moby-dev-bounces@portal.open-bio.org] On Behalf Of Yan Wong Sent: maandag 13 december 2004 10:44 To: Core developer announcements Subject: Re: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices You should have: -Output query name should be the same as Input query name: (Input : I have 'query1' as name for the query and I get '9054'?) -You seems to send a collection of identifiers, so you should return a collection of objects. With the Python API, just put your set of objects in a tuple: ('collectionName' , [object1, object2, object3, etc..]) the mobyContent will serialize the collection into this: -you return an object with namespace=WatDB inside the content. maybe is it better to put it in a cross reference: o=MobyObject(namespace='PO_acc', id='118') o._cross=[MobyObject(namespace='WatDB', id='118'] ( don' forget the [] because it is a set of objects) or use the MobyXref object to build a Xref object (defined in the Moby-s v0.8 API) from bioMoby import MobyXref xref=MobyXref("EMBL","X1112345", "www.illuminae.com","getEMBLRecord", "IEA", transform") see help(MobyXref) for details. or you want to return an object with WatDB namespace and id: o=MobyObject(namespace='WatDB', id='118') In all case, you must register WatDB as a namespace in the bioMoby directory: >>> from bioMoby import Namespace >>> watdb=Namespace(namespaceType="WatDB", contact="contact@host.domain", authURI="host.domain", description=" a small description of this object") If you want to register on another central than bioMoby: >>> from bioMoby import Central >>> newCentral=Central(url="URL_of_another_bioMoby_directory", ns="http://another_namespace") (see help(Central) for the other instanciation parameters) >>> watdb.central=newCentral and then register your new object: >>> result=watdb.register() and see if it is successful: >>> print result Adamse, Paulien wrote: >-----Original Message----- >From: Adamse, Paulien >Sent: vrijdag 10 december 2004 16:14 >To: 'Core developer announcements' >Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Now the Python API has been fixed I get some results with my service. >Great! But the output is not what it should be. Anybody got an idea >what is wrong with it? At the moment the "content" also contains the >result, but it should be visible for Namespace and Id as well. > >The function is called getWAtDBIdByPOAcc >The function can be called with namespace PO_acc id 9054 > >I could realy use some feedback. > >Thanks in advance >(and have a nice weekend...) > > >Paulien Adamse > >-----Original Message----- >From: moby-dev-bounces@portal.open-bio.org >[mailto:moby-dev-bounces@portal.open-bio.org] On Behalf Of Fiers, Mark >Sent: vrijdag 10 december 2004 15:29 >To: Core developer announcements >Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Thank you very much!!!!! > >It almost works. I had to make one small change (after some searching); >The Body class you've written is identified by a getattr in the module >in question. This does not work since the tag send by >gbrowse_moby is in lowercase. I've worked aroud this by changing 'class >Body:' to 'class body:'. (is it possible to define __getattr__() on >module level??? That would be a nice way to circumvent this problem) > >Concerning Mark's question if gbrowse_moby sends incorrectly formatted >messages? The tag is as far as I understand not a valid soap tag >and apparantly also not part of bioMoby XML. So, I would say that it is >still open for discussion, I'm not an expert on the subject. > >Cheers >Mark > > > > >Yan Wong wrote: > > > >>I've solved the problem and posted corrections to the CVS. >> >>See changelog for listed modifications. >> >>Here are the following steps to do to update your bioMoby Python >>server API: >> >>In your bioMoby python package directory: >> >>-First update your ZSI library with the ZSI library provided by this >>package: >>cd packages >>tar jxvf ZSI-1.5.0-patched-2 >>cd ZSI-1.5.0-patched-2 >>python setup.py install (with your fancy options if you have) >> >>-Update your bioMoby Python library >>python setup.py install (with options) >> >>-Update your scripts by applying the rules: >>however, you'll have to change some things in your script: >> >>BEFORE: >> >>from ZSI import dispatch >>dispatch.AsCGI() >> >>NOW: >> >>from ZSI import dispatch >>from bioMoby.webservice import TCBioMoby >> >>dispatch.AsCGI(typesmodule=TCBioMoby) >> >>or with mod_python: >> >>dispatch.AsHandler(modules=myModule,), request=req, >>typesmodule=TCBioMoby) >> >>TCBioMoby contains a class that serialize/deserialize the content >>inside the tag Body into a MobyContent Object. >> >>This will allow a Python webservice to deal with gbrowse_moby. >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev@biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev@biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev@biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From mwilkinson at mrl.ubc.ca Thu Dec 16 11:30:52 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Dec 16 11:00:50 2004 Subject: [MOBY-dev] extensive updates Message-ID: <1103214652.8319.30.camel@mobycentral.icapture.ubc.ca> Hi all, Those of you running MOBY locally, using any of the MOBY::Client::* libraries, and/or running local copies of gbrowse_moby will need to do an update on *everything* to accommodate the new XML parsing libraries that we are now using. We replaced the XML parser in all core MOBY modules (both client and server side), the gbrowse_moby script itself, and in all of the gbrowse_moby renderers. No new configuration is required - just CVS update and install as usual. This doesn't give us any new functionality right now, but it does mean that we will soon be "safely" parsing XML, since the new library is namespace-aware (until now we have been relying on people using the moby: prefix to mean the same thing... eeek!) Cheers everyone! Mark -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From gordonp at cbr.nrc.ca Thu Dec 16 14:23:54 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Thu Dec 16 14:21:19 2004 Subject: [MOBY-dev] MOBY Central now breaks Java In-Reply-To: References: Message-ID: <41C1E0CA.4040307@cbr.nrc.ca> Hi everyone, MOBY Central code seems to have broken CentralImpl.java. The returned object after a findService call is not well-formed XML, so Axis doesn't let you get very far with debugging. I telneted to port 80 on MOBY Central and POSTed a hand-crafted findService request. You can see the input and output below, but the gist of it is that the Perl parser of the MOBY Central server seems to switch a string for a hash reference somewhere internally while handling the SOAP payload. I think this is a bug in the server-side Perl. Are these errors due to the server code transition currently taking place? A second issue is that the MOBY Central Apache appends its 500 Error page to the SOAP message, making it an invalid XML document. Therefore the real error never propagates to the client, but rather a parsing error ooccurs. Regards, Paul -------------------------------------- Input to mobycentral.cbr.nrc.ca:80 POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-length: 840 Object GO moby 1 1 0 I get the following error returned: HTTP/1.1 500 Internal Server Error Date: Thu, 16 Dec 2004 19:11:59 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 SOAPServer: SOAP::Lite/Perl/0.60 Content-Length: 626 Connection: close Content-Type: text/xml; charset=utf-8 SOAP-ENV:ServerEntity: line 1: error: Start tag expected, '<' not found HASH(0x16a76a0) ^ at /usr/local/lib/perl5/site_perl/5.8.0/MOBY/Central.pm line 2277 500 Internal Server Error

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, markw@illuminae.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.


Apache/1.3.29 Server at mobycentral.cbr.nrc.ca Port 80
From mwilkinson at mrl.ubc.ca Thu Dec 16 15:16:04 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Dec 16 14:45:38 2004 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <41C1E0CA.4040307@cbr.nrc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> Message-ID: <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> Hi Paul, Are you certain that it is still malformed? I think we fixed that problem this morning. ... oh.... wait... it may be that you are hitting the test server. Try it again now that I have restarted it (yes, Phil, sometimes a restart DOES solve the problem ;-) ) If it is still sending out malformed XML I would be surprised, since it isn't breaking the Perl parsers...??? M On Thu, 2004-12-16 at 11:23, Paul Gordon wrote: > Hi everyone, > > MOBY Central code seems to have broken CentralImpl.java. The > returned object after a findService call is not well-formed XML, so Axis > doesn't let you get very far with debugging. I telneted to port 80 on > MOBY Central and POSTed a hand-crafted findService request. You can see > the input and output below, but the gist of it is that the Perl parser > of the MOBY Central server seems to switch a string for a hash reference > somewhere internally while handling the SOAP payload. I think this is a > bug in the server-side Perl. Are these errors due to the server code > transition currently taking place? > > A second issue is that the MOBY Central Apache appends its 500 Error > page to the SOAP message, making it an invalid XML document. Therefore > the real error never propagates to the client, but rather a parsing > error ooccurs. > > Regards, > > Paul > > -------------------------------------- > > Input to mobycentral.cbr.nrc.ca:80 > > POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 > Content-length: 840 > > > xmlns:soap="http://www.w3.org/2001/06/soap-envelope" > soap:encodingStyle="http://www.w3.org/2001/06/soap-encoding"> > > > > > xmlns="http://mobycentral.cbr.nrc.ca/MOBY/Central"> > > > Object > GO > > > > > > > > moby > > 1 > 1 > 0 > > > > > > > > I get the following error returned: > > HTTP/1.1 500 Internal Server Error > Date: Thu, 16 Dec 2004 19:11:59 GMT > Server: Apache/1.3.29 (Unix) mod_perl/1.29 > SOAPServer: SOAP::Lite/Perl/0.60 > Content-Length: 626 > Connection: close > Content-Type: text/xml; charset=utf-8 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://www.w3.org/2001/06/soap-encoding" > xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://www.w3.org/2001/06/soap-encoding">SOAP-ENV:ServerEntity: > line 1: error: Start tag expected, '<' not found > HASH(0x16a76a0) > ^ > at /usr/local/lib/perl5/site_perl/5.8.0/MOBY/Central.pm line 2277 > HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > > 500 Internal Server Error > >

Internal Server Error

> The server encountered an internal error or > misconfiguration and was unable to complete > your request.

> Please contact the server administrator, > markw@illuminae.com and inform them of the time the error occurred, > and anything you might have done that may have > caused the error.

> More information about this error may be available > in the server error log.

>


>
Apache/1.3.29 Server at mobycentral.cbr.nrc.ca Port 80
> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From gordonp at cbr.nrc.ca Thu Dec 16 15:22:43 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Thu Dec 16 15:19:51 2004 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> Message-ID: <41C1EE93.1080903@cbr.nrc.ca> Nope, using the main server and it's still broken. There must be something about the way Perl sets up a SOAP client request that the server Perl parser is expecting, but Axis does not provide. The problem is not (primarily) that malformed XML is sent back from the server, but that it does not properly read the input request XML (instead of a string it tries to parse a hash ref, probably an object handle, at MOBY::Central.pm line 2277). This may in fact be a separate issue from the CentralImpl.java problem, but I can't tell until the response is valid XML (i.e. the default Apache 500 error page is removed from the response). Mark Wilkinson wrote: >Hi Paul, > >Are you certain that it is still malformed? I think we fixed that >problem this morning. > >... oh.... wait... it may be that you are hitting the test server. Try >it again now that I have restarted it (yes, Phil, sometimes a restart >DOES solve the problem ;-) ) > >If it is still sending out malformed XML I would be surprised, since it >isn't breaking the Perl parsers...??? > > From mwilkinson at mrl.ubc.ca Thu Dec 16 15:55:55 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Dec 16 15:25:38 2004 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <41C1EE93.1080903@cbr.nrc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> <41C1EE93.1080903@cbr.nrc.ca> Message-ID: <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> Can you send me the message that it is choking on? (i.e. the on-the-wire XML). I'll send it directly and follow what's happening in trace mode. M On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > Nope, using the main server and it's still broken. There must be > something about the way Perl sets up a SOAP client request that the > server Perl parser is expecting, but Axis does not provide. The problem > is not (primarily) that malformed XML is sent back from the server, but > that it does not properly read the input request XML (instead of a > string it tries to parse a hash ref, probably an object handle, at > MOBY::Central.pm line 2277). > > This may in fact be a separate issue from the CentralImpl.java problem, > but I can't tell until the response is valid XML (i.e. the default > Apache 500 error page is removed from the response). > > Mark Wilkinson wrote: > > >Hi Paul, > > > >Are you certain that it is still malformed? I think we fixed that > >problem this morning. > > > >... oh.... wait... it may be that you are hitting the test server. Try > >it again now that I have restarted it (yes, Phil, sometimes a restart > >DOES solve the problem ;-) ) > > > >If it is still sending out malformed XML I would be surprised, since it > >isn't breaking the Perl parsers...??? > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Thu Dec 16 16:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu Dec 16 15:33:15 2004 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> <41C1EE93.1080903@cbr.nrc.ca> <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> Message-ID: <1103231020.8319.160.camel@mobycentral.icapture.ubc.ca> The strange thing is that the error you are reporting is not appearing in the server logs...? Are you getting back a partial message, or is it a 500 error? M On Thu, 2004-12-16 at 12:55, Mark Wilkinson wrote: > Can you send me the message that it is choking on? (i.e. the > on-the-wire XML). I'll send it directly and follow what's happening in > trace mode. > > M > > > On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > > Nope, using the main server and it's still broken. There must be > > something about the way Perl sets up a SOAP client request that the > > server Perl parser is expecting, but Axis does not provide. The problem > > is not (primarily) that malformed XML is sent back from the server, but > > that it does not properly read the input request XML (instead of a > > string it tries to parse a hash ref, probably an object handle, at > > MOBY::Central.pm line 2277). > > > > This may in fact be a separate issue from the CentralImpl.java problem, > > but I can't tell until the response is valid XML (i.e. the default > > Apache 500 error page is removed from the response). > > > > Mark Wilkinson wrote: > > > > >Hi Paul, > > > > > >Are you certain that it is still malformed? I think we fixed that > > >problem this morning. > > > > > >... oh.... wait... it may be that you are hitting the test server. Try > > >it again now that I have restarted it (yes, Phil, sometimes a restart > > >DOES solve the problem ;-) ) > > > > > >If it is still sending out malformed XML I would be surprised, since it > > >isn't breaking the Perl parsers...??? > > > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev@biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From opushneva at yahoo.ca Fri Dec 17 13:40:23 2004 From: opushneva at yahoo.ca (Nina Opushneva) Date: Fri Dec 17 13:37:28 2004 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103231020.8319.160.camel@mobycentral.icapture.ubc.ca> Message-ID: <20041217184023.89111.qmail@web60907.mail.yahoo.com> Hi Mark, Do you have the highest log level on the Apache server? Maybe it's the problem you have not report about the error. Nina --- Mark Wilkinson wrote: > The strange thing is that the error you are > reporting is not appearing > in the server logs...? Are you getting back a > partial message, or is it > a 500 error? > > M > > > On Thu, 2004-12-16 at 12:55, Mark Wilkinson wrote: > > Can you send me the message that it is choking on? > (i.e. the > > on-the-wire XML). I'll send it directly and > follow what's happening in > > trace mode. > > > > M > > > > > > On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > > > Nope, using the main server and it's still > broken. There must be > > > something about the way Perl sets up a SOAP > client request that the > > > server Perl parser is expecting, but Axis does > not provide. The problem > > > is not (primarily) that malformed XML is sent > back from the server, but > > > that it does not properly read the input request > XML (instead of a > > > string it tries to parse a hash ref, probably an > object handle, at > > > MOBY::Central.pm line 2277). > > > > > > This may in fact be a separate issue from the > CentralImpl.java problem, > > > but I can't tell until the response is valid XML > (i.e. the default > > > Apache 500 error page is removed from the > response). > > > > > > Mark Wilkinson wrote: > > > > > > >Hi Paul, > > > > > > > >Are you certain that it is still malformed? I > think we fixed that > > > >problem this morning. > > > > > > > >... oh.... wait... it may be that you are > hitting the test server. Try > > > >it again now that I have restarted it (yes, > Phil, sometimes a restart > > > >DOES solve the problem ;-) ) > > > > > > > >If it is still sending out malformed XML I > would be surprised, since it > > > >isn't breaking the Perl parsers...??? > > > > > > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev@biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Assistant Professor (Bioinformatics) > Dept. Medical Genetics, UBC, Canada > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev@biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From wong.yan at netcourrier.com Thu Dec 2 11:39:56 2004 From: wong.yan at netcourrier.com (wong.yan@netcourrier.com) Date: Thu, 2 Dec 2004 11:39:56 CET Subject: [MOBY-dev] question about the bioMoby python API Message-ID: one other solution is to put a type attribute on the body tag: the CORRECT message should be: your MobyContent in XML ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) From mark.fiers at wur.nl Thu Dec 2 08:19:59 2004 From: mark.fiers at wur.nl (Mark Fiers) Date: Thu, 02 Dec 2004 14:19:59 +0100 Subject: [MOBY-dev] question about the bioMoby python API In-Reply-To: References: Message-ID: <41AF167F.10001@wur.nl> wong.yan at netcourrier.com wrote: >one other solution is to put a type attribute on the body tag: > > But, if i am not mistaking, that would then have to be done by the people running http://mobycentral.cbr.nrc.ca/cgi-bin/gbrowse_moby since this site generates the ?'faulty'? body tag. (is it faulty? or is it still a valid soap call? Would a workaround be to edit the zsi code to default to a string if it doesn't find a xsi:type attribute? Or would that cause different problems? Mark >the CORRECT message should be: >your MobyContent in XML > > >------------------------------------------------------------- >NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... >Web/Wap : www.netcourrier.com >T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) >Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From wong.yan at netcourrier.com Thu Dec 2 21:13:47 2004 From: wong.yan at netcourrier.com (wong.yan@netcourrier.com) Date: Thu, 2 Dec 2004 21:13:47 CET Subject: [MOBY-dev] question about the bioMoby python API Message-ID: at my level, I believe it is an error, because the tag represent an object with a string inside (so what's the use of the body tag??). However, the SOAP call is still valid (so I work on a workaround for it). A work around on the ZSI patch will surely solve this issue, I am working it but at little speed... look at the file ZSI-1.5.0-patched/ZSI/TC.py: at the line: 254: if len(_child_elements(elt)) == 0: raise EvaluateException("Any cannot parse untyped element", ps.Backtrace(elt)) maybe a "return elt" (elt as a string) instead of "raise Exception etc.." should be sufficient... however, the Body is followed by the <[CDATA tag, this tag should be dropped in order to treat the MobyContent There may be another solution, define a class call Body but ZSI, the technique is described in the ZSI documentation page but the example with the "from ZSI import Path" doesn't work as the Path file is inexistant and make the script fail. link to the documentation of ZSI http://pywebsvcs.sourceforge.net/zsi.html see chapter 2.2.2 for defining a class for ZSI. ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) From mwilkinson at mobile.rogers.com Fri Dec 3 08:57:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 08:57:10 -0500 Subject: [MOBY-dev] Test request Message-ID: <200412031355.iB3DtlKr006219@portal.open-bio.org> Hi everyone, Can a few of you test mobycentral to see if it works for you? It is working for me (in my hotel room), but not for Rebecca nor Martin... I'm wondering if it is the connection between europe and here? M !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Fri Dec 3 13:05:14 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 13:05:14 -0500 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031804.iB3I47Kr008138@portal.open-bio.org> I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) Can our European partners keep an eye on it and let me know when it comes back up? Thanks! M !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From beatrice at arabidopsis.info Fri Dec 3 13:16:21 2004 From: beatrice at arabidopsis.info (Beatrice Schildknecht) Date: Fri, 03 Dec 2004 18:16:21 +0000 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> References: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: <41B0AD75.3060400@arabidopsis.info> I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From beatrice at arabidopsis.info Fri Dec 3 13:16:21 2004 From: beatrice at arabidopsis.info (Beatrice Schildknecht) Date: Fri, 03 Dec 2004 18:16:21 +0000 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> References: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: <41B0AD75.3060400@arabidopsis.info> I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From mwilkinson at mobile.rogers.com Fri Dec 3 13:18:54 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 13:18:54 -0500 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031818.iB3IIkKr008258@portal.open-bio.org> Ha! So Beatrice does live on! You should have stayed silent - now I will chase you down to fix your broken services ;-) M -----Original Message----- From: Beatrice Schildknecht Date: Fri, 03 Dec 2004 18:16:21 To:mwilkinson , Core developer announcements Cc:Moby-dev at open-bio.org Subject: Re: [MOBY-dev] It appears to be a European problem... I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Fri Dec 3 13:18:54 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 13:18:54 -0500 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031818.iB3IIlKr008262@portal.open-bio.org> Ha! So Beatrice does live on! You should have stayed silent - now I will chase you down to fix your broken services ;-) M -----Original Message----- From: Beatrice Schildknecht Date: Fri, 03 Dec 2004 18:16:21 To:mwilkinson , Core developer announcements Cc:Moby-dev at open-bio.org Subject: Re: [MOBY-dev] It appears to be a European problem... I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Fri Dec 3 13:45:16 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 3 Dec 2004 18:45:16 +0000 (GMT) Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: > Can our European partners keep an eye on it and let me know when it comes back up? > Well, England is back in the bussiness: [senger at localhost jMoby]$ build/run/run-testing-central retrieveServiceNames OK retrieveServiceProviders OK retrieveServiceTypes OK retrieveNamespaces OK retrieveObjectNames OK registerServiceType OK registerNamespace - 1 OK registerNamespace - 2 OK registerDataType - 1 OK registerDataType - 3 OK registerDataType - 2 OK getDataTypeDefinition - 2 OK registerService OK deregisterService OK deregisterDataType - 2 OK deregisterDataType - 3 OK deregisterDataType - 1 OK deregisterNamespace - 2 OK deregisterNamespace - 1 OK deregisterServiceType OK Thanks, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From duncan.hull at cs.man.ac.uk Tue Dec 7 04:11:59 2004 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Tue, 07 Dec 2004 09:11:59 +0000 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: References: Message-ID: <41B573DF.50501@cs.man.ac.uk> Martin Senger wrote: > Well, England is back in the bussiness: > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From d.haase at gsf.de Tue Dec 7 04:43:16 2004 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 7 Dec 2004 10:43:16 +0100 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <41B573DF.50501@cs.man.ac.uk> References: <41B573DF.50501@cs.man.ac.uk> Message-ID: <200412071043.16612.d.haase@gsf.de> On Tuesday 07 December 2004 10:11, Duncan Hull wrote: > Martin Senger wrote: > > Well, England is back in the bussiness: > > > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, > which was working fine last night. Does anyone else in Europe have the > same problem? Yep, Germany is locked out as well. It went somehow in the early morning (~8am MET), but veeeeryyyy slow... Now it's completely gone :-( dirk From m.rouard at cgiar.org Tue Dec 7 04:56:15 2004 From: m.rouard at cgiar.org (Rouard, Mathieu (INIBAP - Montpellier)) Date: Tue, 07 Dec 2004 01:56:15 -0800 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <31AB896A0E7ED211BFBE0008C7283D13F936B3@inibapnt1.inibap.org> Hi Duncan, I have also some trouble in france today . I cannot connect to mobycentral. regards, mathieu -- Mathieu Rouard IPGRI-INIBAP < www.inibap.org > Parc Scientifique Agropolis II 34397 Montpellier - Cedex 5 - France Tel: +33 (0)467 61 13 02 Fax: +33 (0)467 61 03 34 -----Original Message----- From: Duncan Hull [mailto:duncan.hull at cs.man.ac.uk] Sent: mardi 7 d?cembre 2004 10:12 Cc: Moby-dev at open-bio.org; Mark Wilkinson Subject: Re: [MOBY-dev] It appears to be a European problem... Martin Senger wrote: > Well, England is back in the bussiness: > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From m.rouard at cgiar.org Tue Dec 7 04:56:15 2004 From: m.rouard at cgiar.org (Rouard, Mathieu (INIBAP - Montpellier)) Date: Tue, 07 Dec 2004 01:56:15 -0800 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <31AB896A0E7ED211BFBE0008C7283D13F936B3@inibapnt1.inibap.org> Hi Duncan, I have also some trouble in france today . I cannot connect to mobycentral. regards, mathieu -- Mathieu Rouard IPGRI-INIBAP < www.inibap.org > Parc Scientifique Agropolis II 34397 Montpellier - Cedex 5 - France Tel: +33 (0)467 61 13 02 Fax: +33 (0)467 61 03 34 -----Original Message----- From: Duncan Hull [mailto:duncan.hull at cs.man.ac.uk] Sent: mardi 7 d?cembre 2004 10:12 Cc: Moby-dev at open-bio.org; Mark Wilkinson Subject: Re: [MOBY-dev] It appears to be a European problem... Martin Senger wrote: > Well, England is back in the bussiness: > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Dec 7 04:56:02 2004 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 7 Dec 2004 10:56:02 +0100 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412071043.16612.d.haase@gsf.de> References: <41B573DF.50501@cs.man.ac.uk> <200412071043.16612.d.haase@gsf.de> Message-ID: <200412071056.02072.d.haase@gsf.de> On Tuesday 07 December 2004 10:43, Dirk Haase wrote: > On Tuesday 07 December 2004 10:11, Duncan Hull wrote: > > Martin Senger wrote: > > > Well, England is back in the bussiness: > > > > > >[senger at localhost jMoby]$ build/run/run-testing-central > > > > I'm having trouble running mobycentral from Martins latest jMoby client, > > which was working fine last night. Does anyone else in Europe have the > > same problem? > > Yep, Germany is locked out as well. It went somehow in the early morning > (~8am MET), but veeeeryyyy slow... Now it's completely gone :-( ... and _now_ it's ok again. Thanks to whoever... From mwilkinson at mrl.ubc.ca Tue Dec 7 12:21:02 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 07 Dec 2004 09:21:02 -0800 Subject: [MOBY-dev] [Fwd: [personal] Re: Intermittent loss of MOBY from Europe] Message-ID: <1102440061.16721.22.camel@mobycentral.icapture.ubc.ca> Hi all, Since your reports are generally coming in while I am sleeping and the problem is fixed by the time I wake up, can I ask you to do these tests next time you find that you cannot connect to MOBY Central? It's happened a few times in the past two weeks, and I'd like to know what the source of the problem is. thanks! M > Hi Mark, > > All of our tests show that the Moby service is reachable via Europe. > Next time you suspect connectivity problems, please go to: > > www.traceroute.org > > and try a few tests from the various links in Europe to see where the > problem lies. Then, if you can send us the output from your tests, we > should be able to determine if the problem lies in our network or > externally. Most of the links on this site have options to traceroute to > an IP (others have ping and other services available). -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From ywong at infobiogen.fr Wed Dec 8 11:17:22 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Wed, 08 Dec 2004 17:17:22 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: <41B72912.6030702@infobiogen.fr> I've solved the problem and posted corrections to the CVS. See changelog for listed modifications. Here are the following steps to do to update your bioMoby Python server API: In your bioMoby python package directory: -First update your ZSI library with the ZSI library provided by this package: cd packages tar jxvf ZSI-1.5.0-patched-2 cd ZSI-1.5.0-patched-2 python setup.py install (with your fancy options if you have) -Update your bioMoby Python library python setup.py install (with options) -Update your scripts by applying the rules: however, you'll have to change some things in your script: BEFORE: from ZSI import dispatch dispatch.AsCGI() NOW: from ZSI import dispatch from bioMoby.webservice import TCBioMoby dispatch.AsCGI(typesmodule=TCBioMoby) or with mod_python: dispatch.AsHandler(modules=myModule,), request=req, typesmodule=TCBioMoby) TCBioMoby contains a class that serialize/deserialize the content inside the tag Body into a MobyContent Object. This will allow a Python webservice to deal with gbrowse_moby. From mwilkinson at mrl.ubc.ca Wed Dec 8 11:54:01 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 08 Dec 2004 08:54:01 -0800 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > This will allow a Python webservice to deal with gbrowse_moby. Does gbrowse_moby send incorrectly formatted messages? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Wed Dec 8 11:54:01 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 08 Dec 2004 08:54:01 -0800 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > This will allow a Python webservice to deal with gbrowse_moby. Does gbrowse_moby send incorrectly formatted messages? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From ywong at infobiogen.fr Wed Dec 8 12:05:53 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Wed, 08 Dec 2004 18:05:53 +0100 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: <41B72912.6030702@infobiogen.fr> <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> Message-ID: <41B73471.8020701@infobiogen.fr> AFAIK no, it doesn't. It is just a matter of mapping between XML objects and Python objects. As I have never used gbrowse_moby to test my services, I didn't know the MobyContent object was included in a body tag. My soap call send the MobyContent inside a string object: MobyContent Mark Wilkinson wrote: >On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > > > > >>This will allow a Python webservice to deal with gbrowse_moby. >> >> > > >Does gbrowse_moby send incorrectly formatted messages? > >M > > > > From mark.fiers at wur.nl Fri Dec 10 09:29:27 2004 From: mark.fiers at wur.nl (Mark Fiers) Date: Fri, 10 Dec 2004 15:29:27 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <41B9B2C7.6090901@wur.nl> Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From paulien.adamse at wur.nl Fri Dec 10 10:13:52 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Fri, 10 Dec 2004 16:13:52 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: Now the Python API has been fixed I get some results with my service. Great! But the output is not what it should be. Anybody got an idea what is wrong with it? At the moment the "content" also contains the result, but it should be visible for Namespace and Id as well. The function is called getWAtDBIdByPOAcc The function can be called with namespace PO_acc id 9054 I could realy use some feedback. Thanks in advance (and have a nice weekend...) Paulien Adamse -----Original Message----- From: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark Sent: vrijdag 10 december 2004 15:29 To: Core developer announcements Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From paulien.adamse at wur.nl Fri Dec 10 10:17:26 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Fri, 10 Dec 2004 16:17:26 +0100 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: -----Original Message----- From: Adamse, Paulien Sent: vrijdag 10 december 2004 16:14 To: 'Core developer announcements' Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Now the Python API has been fixed I get some results with my service. Great! But the output is not what it should be. Anybody got an idea what is wrong with it? At the moment the "content" also contains the result, but it should be visible for Namespace and Id as well. The function is called getWAtDBIdByPOAcc The function can be called with namespace PO_acc id 9054 I could realy use some feedback. Thanks in advance (and have a nice weekend...) Paulien Adamse -----Original Message----- From: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark Sent: vrijdag 10 december 2004 15:29 To: Core developer announcements Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Sat Dec 11 12:38:57 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 11 Dec 2004 09:38:57 -0800 Subject: [MOBY-dev] A few new tools and updates Message-ID: <41BB30B1.8040105@illuminae.com> Hi all, Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: 1) Eddie has finished writing applets that help in the construction of new tools for creating objects,service types, and registering new service instances. Try them at: http://mobycentral.cbr.nrc.ca/applets (note that this is operating on the "live" database) 2) For a variety of reasons we've decided to change the structure of the Service Instance RDF. As such, I have temporarily switched the deregisterService function back 'on' in MOBY Central. You can deregister services as before using the API. 3) Once we have a good RDF generator, we will ask you again to retrieve the RDF of your services and we'll switch Nina's agent on. I'll then switch the deregisterService function 'off' again. Cheers all! Mark P.S. I'm planning to host the next (possibly last, depending on funding...) MOBY developers meeting in Vancouver in early May, 2005. Does anyone know of other conferences going on that we should avoid conflicting with? From ywong at infobiogen.fr Mon Dec 13 04:43:46 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon, 13 Dec 2004 10:43:46 +0100 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: Message-ID: <41BD6452.7090105@infobiogen.fr> You should have: -Output query name should be the same as Input query name: (Input : I have 'query1' as name for the query and I get '9054'?) -You seems to send a collection of identifiers, so you should return a collection of objects. With the Python API, just put your set of objects in a tuple: ('collectionName' , [object1, object2, object3, etc..]) the mobyContent will serialize the collection into this: -you return an object with namespace=WatDB inside the content. maybe is it better to put it in a cross reference: o=MobyObject(namespace='PO_acc', id='118') o._cross=[MobyObject(namespace='WatDB', id='118'] ( don' forget the [] because it is a set of objects) or use the MobyXref object to build a Xref object (defined in the Moby-s v0.8 API) from bioMoby import MobyXref xref=MobyXref("EMBL","X1112345", "www.illuminae.com","getEMBLRecord", "IEA", transform") see help(MobyXref) for details. or you want to return an object with WatDB namespace and id: o=MobyObject(namespace='WatDB', id='118') In all case, you must register WatDB as a namespace in the bioMoby directory: >>> from bioMoby import Namespace >>> watdb=Namespace(namespaceType="WatDB", contact="contact at host.domain", authURI="host.domain", description=" a small description of this object") If you want to register on another central than bioMoby: >>> from bioMoby import Central >>> newCentral=Central(url="URL_of_another_bioMoby_directory", ns="http://another_namespace") (see help(Central) for the other instanciation parameters) >>> watdb.central=newCentral and then register your new object: >>> result=watdb.register() and see if it is successful: >>> print result Adamse, Paulien wrote: >-----Original Message----- >From: Adamse, Paulien >Sent: vrijdag 10 december 2004 16:14 >To: 'Core developer announcements' >Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Now the Python API has been fixed I get some results with my service. >Great! But the output is not what it should be. Anybody got an idea what >is wrong with it? At the moment the "content" also contains the result, >but it should be visible for Namespace and Id as well. > >The function is called getWAtDBIdByPOAcc >The function can be called with namespace PO_acc id 9054 > >I could realy use some feedback. > >Thanks in advance >(and have a nice weekend...) > > >Paulien Adamse > >-----Original Message----- >From: moby-dev-bounces at portal.open-bio.org >[mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark >Sent: vrijdag 10 december 2004 15:29 >To: Core developer announcements >Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Thank you very much!!!!! > >It almost works. I had to make one small change (after some searching); >The Body class you've written is identified by a getattr in the module >in question. This does not work since the tag send by >gbrowse_moby is in lowercase. I've worked aroud this by changing 'class >Body:' to 'class body:'. (is it possible to define __getattr__() on >module level??? That would be a nice way to circumvent this problem) > >Concerning Mark's question if gbrowse_moby sends incorrectly formatted >messages? The tag is as far as I understand not a valid soap tag >and apparantly also not part of bioMoby XML. So, I would say that it is >still open for discussion, I'm not an expert on the subject. > >Cheers >Mark > > > > >Yan Wong wrote: > > > >>I've solved the problem and posted corrections to the CVS. >> >>See changelog for listed modifications. >> >>Here are the following steps to do to update your bioMoby Python >>server API: >> >>In your bioMoby python package directory: >> >>-First update your ZSI library with the ZSI library provided by this >>package: >>cd packages >>tar jxvf ZSI-1.5.0-patched-2 >>cd ZSI-1.5.0-patched-2 >>python setup.py install (with your fancy options if you have) >> >>-Update your bioMoby Python library >>python setup.py install (with options) >> >>-Update your scripts by applying the rules: >>however, you'll have to change some things in your script: >> >>BEFORE: >> >>from ZSI import dispatch >>dispatch.AsCGI() >> >>NOW: >> >>from ZSI import dispatch >>from bioMoby.webservice import TCBioMoby >> >>dispatch.AsCGI(typesmodule=TCBioMoby) >> >>or with mod_python: >> >>dispatch.AsHandler(modules=myModule,), request=req, >>typesmodule=TCBioMoby) >> >>TCBioMoby contains a class that serialize/deserialize the content >>inside the tag Body into a MobyContent Object. >> >>This will allow a Python webservice to deal with gbrowse_moby. >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From ywong at infobiogen.fr Mon Dec 13 04:56:45 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon, 13 Dec 2004 10:56:45 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: <41B72912.6030702@infobiogen.fr> <41B9B2C7.6090901@wur.nl> Message-ID: <41BD675D.9000405@infobiogen.fr> The best way maybe it is to add another class in the TCBioMoby file: class body(Body): pass but then when you return the MobyContent to the client you should add: from bioMoby.webservice import TCBioMoby mobyContentToBeReturned=MobyContent(ResultsOfTheTreatments) mobyContentToBeReturned.typecode=TCBioMoby.body() #tell how ZSI should serialize mobyContentToBeReturned return mc Mark Fiers wrote: > Thank you very much!!!!! > > It almost works. I had to make one small change (after some > searching); The Body class you've written is identified by a getattr > in the module in question. This does not work since the tag > send by gbrowse_moby is in lowercase. I've worked aroud this by > changing 'class Body:' to 'class body:'. (is it possible to define > __getattr__() on module level??? That would be a nice way to > circumvent this problem) > > Concerning Mark's question if gbrowse_moby sends incorrectly formatted > messages? The tag is as far as I understand not a valid soap > tag and apparantly also not part of bioMoby XML. So, I would say that > it is still open for discussion, I'm not an expert on the subject. > > Cheers > Mark > > > > > Yan Wong wrote: > >> >> I've solved the problem and posted corrections to the CVS. >> >> See changelog for listed modifications. >> >> Here are the following steps to do to update your bioMoby Python >> server API: >> >> In your bioMoby python package directory: >> >> -First update your ZSI library with the ZSI library provided by this >> package: >> cd packages >> tar jxvf ZSI-1.5.0-patched-2 >> cd ZSI-1.5.0-patched-2 >> python setup.py install (with your fancy options if you have) >> >> -Update your bioMoby Python library >> python setup.py install (with options) >> >> -Update your scripts by applying the rules: >> however, you'll have to change some things in your script: >> >> BEFORE: >> >> from ZSI import dispatch >> dispatch.AsCGI() >> >> NOW: >> >> from ZSI import dispatch >> from bioMoby.webservice import TCBioMoby >> >> dispatch.AsCGI(typesmodule=TCBioMoby) >> >> or with mod_python: >> >> dispatch.AsHandler(modules=myModule,), request=req, >> typesmodule=TCBioMoby) >> >> TCBioMoby contains a class that serialize/deserialize the content >> inside the tag Body into a MobyContent Object. >> >> This will allow a Python webservice to deal with gbrowse_moby. >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From ywong at infobiogen.fr Mon Dec 13 08:43:46 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon, 13 Dec 2004 14:43:46 +0100 Subject: [MOBY-dev] register recursive types Message-ID: <41BD9C92.6000108@infobiogen.fr> Is it possible to register recursive types in a bioMoby directory? I tried this: 1: AbstactNode ISA Object Nodelist ISA Object HAS AbstractNode Node ISA AbstractNode HASA NodeList are there other solutions? From rebecca.ernst at gsf.de Mon Dec 13 11:20:27 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon, 13 Dec 2004 17:20:27 +0100 Subject: [MOBY-dev] registration of services not possible yet In-Reply-To: <41BB30B1.8040105@illuminae.com> References: <41BB30B1.8040105@illuminae.com> Message-ID: <41BDC14B.1020804@gsf.de> Hi Mark! I just tried to deregister/register my services - it still tells me that I am not allowed to deregister a service that is registered having a RDF!! Rebecca Mark Wilkinson wrote: > Hi all, > > Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: > > 1) Eddie has finished writing applets that help in the construction > of new tools for creating objects,service types, and registering new > service instances. Try them at: > http://mobycentral.cbr.nrc.ca/applets (note that this is operating on > the "live" database) > > 2) For a variety of reasons we've decided to change the structure of > the Service Instance RDF. As such, I have temporarily switched the > deregisterService function back 'on' in MOBY Central. You can > deregister services as before using the API. > > 3) Once we have a good RDF generator, we will ask you again to > retrieve the RDF of your services and we'll switch Nina's agent on. > I'll then switch the deregisterService function 'off' again. > > Cheers all! > Mark > > P.S. I'm planning to host the next (possibly last, depending on > funding...) MOBY developers meeting in Vancouver in early May, 2005. > Does anyone know of other conferences going on that we should avoid > conflicting with? > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From mwilkinson at mrl.ubc.ca Mon Dec 13 12:53:21 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon, 13 Dec 2004 09:53:21 -0800 Subject: [MOBY-dev] Re: [moby] [MOBY-l] registration of services not possible yet In-Reply-To: <41BDC14B.1020804@gsf.de> References: <41BB30B1.8040105@illuminae.com> <41BDC14B.1020804@gsf.de> Message-ID: <1102960400.30331.26.camel@mobycentral.icapture.ubc.ca> Doh! I forgot to restart the server. Try now... M On Mon, 2004-12-13 at 08:20, Rebecca Ernst wrote: > Hi Mark! > > I just tried to deregister/register my services - it still tells me that > I am not allowed to deregister a service that is registered having a RDF!! > > Rebecca > > > > > Mark Wilkinson wrote: > > > Hi all, > > > > Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: > > > > 1) Eddie has finished writing applets that help in the construction > > of new tools for creating objects,service types, and registering new > > service instances. Try them at: > > http://mobycentral.cbr.nrc.ca/applets (note that this is operating on > > the "live" database) > > > > 2) For a variety of reasons we've decided to change the structure of > > the Service Instance RDF. As such, I have temporarily switched the > > deregisterService function back 'on' in MOBY Central. You can > > deregister services as before using the API. > > > > 3) Once we have a good RDF generator, we will ask you again to > > retrieve the RDF of your services and we'll switch Nina's agent on. > > I'll then switch the deregisterService function 'off' again. > > > > Cheers all! > > Mark > > > > P.S. I'm planning to host the next (possibly last, depending on > > funding...) MOBY developers meeting in Vancouver in early May, 2005. > > Does anyone know of other conferences going on that we should avoid > > conflicting with? > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Mon Dec 13 13:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon, 13 Dec 2004 10:03:40 -0800 Subject: [moby] [MOBY-dev] register recursive types In-Reply-To: <41BD9C92.6000108@infobiogen.fr> References: <41BD9C92.6000108@infobiogen.fr> Message-ID: <1102961020.30331.38.camel@mobycentral.icapture.ubc.ca> I'm not quite sure what you are trying to achieve in that set of objects...?? M On Mon, 2004-12-13 at 05:43, Yan Wong wrote: > Is it possible to register recursive types in a bioMoby directory? > > I tried this: > > 1: > AbstactNode ISA Object > > Nodelist ISA Object HAS AbstractNode > > Node ISA AbstractNode HASA NodeList > > are there other solutions? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Mon Dec 13 13:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon, 13 Dec 2004 10:03:40 -0800 Subject: [moby] [MOBY-dev] register recursive types In-Reply-To: <41BD9C92.6000108@infobiogen.fr> References: <41BD9C92.6000108@infobiogen.fr> Message-ID: <1102961020.30331.38.camel@mobycentral.icapture.ubc.ca> I'm not quite sure what you are trying to achieve in that set of objects...?? M On Mon, 2004-12-13 at 05:43, Yan Wong wrote: > Is it possible to register recursive types in a bioMoby directory? > > I tried this: > > 1: > AbstactNode ISA Object > > Nodelist ISA Object HAS AbstractNode > > Node ISA AbstractNode HASA NodeList > > are there other solutions? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From rebecca.ernst at gsf.de Tue Dec 14 04:01:37 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Tue, 14 Dec 2004 10:01:37 +0100 Subject: [MOBY-dev] service deregistration Message-ID: <41BEABF1.4050902@gsf.de> Hi Mark! the server restart didn't solve the problem. I still can only deregister services which are registered without RDF. Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From mwilkinson at mrl.ubc.ca Tue Dec 14 11:37:44 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 14 Dec 2004 08:37:44 -0800 Subject: [MOBY-dev] Re: [moby] [MOBY-l] service deregistration In-Reply-To: <41BEABF1.4050902@gsf.de> References: <41BEABF1.4050902@gsf.de> Message-ID: <1103042264.32326.34.camel@mobycentral.icapture.ubc.ca> Doh! DOH! You're right. The MOBY Central code is currently broken. Eddie is going to troubleshoot, and hopefully we'll have it up by the end of the day. In the meantime, MOBY Central is running on an older codebase, so almost everything is functioning properly. I'll restart the server again when the problem is identified. Sorry! M On Tue, 2004-12-14 at 01:01, Rebecca Ernst wrote: > Hi Mark! > > the server restart didn't solve the problem. I still can only deregister > services which are registered without RDF. > > Rebecca -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Tue Dec 14 19:45:52 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 14 Dec 2004 16:45:52 -0800 Subject: [MOBY-dev] For those who wanted tomcat on MOBY Central Message-ID: <1103071552.591.63.camel@mobycentral.icapture.ubc.ca> Hi all, I've had a few requests for a Tomcat installation on MOBY Central to deploy a variety of things there. Can I just check with those who have requested this whether you need Tomcat to be running through apache, or simply using its standalone server? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From paulien.adamse at wur.nl Wed Dec 15 02:49:30 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Wed, 15 Dec 2004 08:49:30 +0100 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: Hi Yan Wong, Thanks for your detailed response. It should be possible to make it work now! Paulien PS I already registered the namespace WAtDB_Id. And put it in the content just to see some output. Don't intend to keep showing it there. Paulien Adamse Applied Bioinformatics Kamer 0.210 Tel. (4)76850 -----Original Message----- From: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Yan Wong Sent: maandag 13 december 2004 10:44 To: Core developer announcements Subject: Re: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices You should have: -Output query name should be the same as Input query name: (Input : I have 'query1' as name for the query and I get '9054'?) -You seems to send a collection of identifiers, so you should return a collection of objects. With the Python API, just put your set of objects in a tuple: ('collectionName' , [object1, object2, object3, etc..]) the mobyContent will serialize the collection into this: -you return an object with namespace=WatDB inside the content. maybe is it better to put it in a cross reference: o=MobyObject(namespace='PO_acc', id='118') o._cross=[MobyObject(namespace='WatDB', id='118'] ( don' forget the [] because it is a set of objects) or use the MobyXref object to build a Xref object (defined in the Moby-s v0.8 API) from bioMoby import MobyXref xref=MobyXref("EMBL","X1112345", "www.illuminae.com","getEMBLRecord", "IEA", transform") see help(MobyXref) for details. or you want to return an object with WatDB namespace and id: o=MobyObject(namespace='WatDB', id='118') In all case, you must register WatDB as a namespace in the bioMoby directory: >>> from bioMoby import Namespace >>> watdb=Namespace(namespaceType="WatDB", contact="contact at host.domain", authURI="host.domain", description=" a small description of this object") If you want to register on another central than bioMoby: >>> from bioMoby import Central >>> newCentral=Central(url="URL_of_another_bioMoby_directory", ns="http://another_namespace") (see help(Central) for the other instanciation parameters) >>> watdb.central=newCentral and then register your new object: >>> result=watdb.register() and see if it is successful: >>> print result Adamse, Paulien wrote: >-----Original Message----- >From: Adamse, Paulien >Sent: vrijdag 10 december 2004 16:14 >To: 'Core developer announcements' >Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Now the Python API has been fixed I get some results with my service. >Great! But the output is not what it should be. Anybody got an idea >what is wrong with it? At the moment the "content" also contains the >result, but it should be visible for Namespace and Id as well. > >The function is called getWAtDBIdByPOAcc >The function can be called with namespace PO_acc id 9054 > >I could realy use some feedback. > >Thanks in advance >(and have a nice weekend...) > > >Paulien Adamse > >-----Original Message----- >From: moby-dev-bounces at portal.open-bio.org >[mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark >Sent: vrijdag 10 december 2004 15:29 >To: Core developer announcements >Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Thank you very much!!!!! > >It almost works. I had to make one small change (after some searching); >The Body class you've written is identified by a getattr in the module >in question. This does not work since the tag send by >gbrowse_moby is in lowercase. I've worked aroud this by changing 'class >Body:' to 'class body:'. (is it possible to define __getattr__() on >module level??? That would be a nice way to circumvent this problem) > >Concerning Mark's question if gbrowse_moby sends incorrectly formatted >messages? The tag is as far as I understand not a valid soap tag >and apparantly also not part of bioMoby XML. So, I would say that it is >still open for discussion, I'm not an expert on the subject. > >Cheers >Mark > > > > >Yan Wong wrote: > > > >>I've solved the problem and posted corrections to the CVS. >> >>See changelog for listed modifications. >> >>Here are the following steps to do to update your bioMoby Python >>server API: >> >>In your bioMoby python package directory: >> >>-First update your ZSI library with the ZSI library provided by this >>package: >>cd packages >>tar jxvf ZSI-1.5.0-patched-2 >>cd ZSI-1.5.0-patched-2 >>python setup.py install (with your fancy options if you have) >> >>-Update your bioMoby Python library >>python setup.py install (with options) >> >>-Update your scripts by applying the rules: >>however, you'll have to change some things in your script: >> >>BEFORE: >> >>from ZSI import dispatch >>dispatch.AsCGI() >> >>NOW: >> >>from ZSI import dispatch >>from bioMoby.webservice import TCBioMoby >> >>dispatch.AsCGI(typesmodule=TCBioMoby) >> >>or with mod_python: >> >>dispatch.AsHandler(modules=myModule,), request=req, >>typesmodule=TCBioMoby) >> >>TCBioMoby contains a class that serialize/deserialize the content >>inside the tag Body into a MobyContent Object. >> >>This will allow a Python webservice to deal with gbrowse_moby. >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From mwilkinson at mrl.ubc.ca Thu Dec 16 11:30:52 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 08:30:52 -0800 Subject: [MOBY-dev] extensive updates Message-ID: <1103214652.8319.30.camel@mobycentral.icapture.ubc.ca> Hi all, Those of you running MOBY locally, using any of the MOBY::Client::* libraries, and/or running local copies of gbrowse_moby will need to do an update on *everything* to accommodate the new XML parsing libraries that we are now using. We replaced the XML parser in all core MOBY modules (both client and server side), the gbrowse_moby script itself, and in all of the gbrowse_moby renderers. No new configuration is required - just CVS update and install as usual. This doesn't give us any new functionality right now, but it does mean that we will soon be "safely" parsing XML, since the new library is namespace-aware (until now we have been relying on people using the moby: prefix to mean the same thing... eeek!) Cheers everyone! Mark -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From gordonp at cbr.nrc.ca Thu Dec 16 14:23:54 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Thu, 16 Dec 2004 12:23:54 -0700 Subject: [MOBY-dev] MOBY Central now breaks Java In-Reply-To: References: Message-ID: <41C1E0CA.4040307@cbr.nrc.ca> Hi everyone, MOBY Central code seems to have broken CentralImpl.java. The returned object after a findService call is not well-formed XML, so Axis doesn't let you get very far with debugging. I telneted to port 80 on MOBY Central and POSTed a hand-crafted findService request. You can see the input and output below, but the gist of it is that the Perl parser of the MOBY Central server seems to switch a string for a hash reference somewhere internally while handling the SOAP payload. I think this is a bug in the server-side Perl. Are these errors due to the server code transition currently taking place? A second issue is that the MOBY Central Apache appends its 500 Error page to the SOAP message, making it an invalid XML document. Therefore the real error never propagates to the client, but rather a parsing error ooccurs. Regards, Paul -------------------------------------- Input to mobycentral.cbr.nrc.ca:80 POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-length: 840 Object GO moby 1 1 0 I get the following error returned: HTTP/1.1 500 Internal Server Error Date: Thu, 16 Dec 2004 19:11:59 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 SOAPServer: SOAP::Lite/Perl/0.60 Content-Length: 626 Connection: close Content-Type: text/xml; charset=utf-8 SOAP-ENV:ServerEntity: line 1: error: Start tag expected, '<' not found HASH(0x16a76a0) ^ at /usr/local/lib/perl5/site_perl/5.8.0/MOBY/Central.pm line 2277 500 Internal Server Error

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, markw at illuminae.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.


Apache/1.3.29 Server at mobycentral.cbr.nrc.ca Port 80
From mwilkinson at mrl.ubc.ca Thu Dec 16 15:16:04 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 12:16:04 -0800 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <41C1E0CA.4040307@cbr.nrc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> Message-ID: <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> Hi Paul, Are you certain that it is still malformed? I think we fixed that problem this morning. ... oh.... wait... it may be that you are hitting the test server. Try it again now that I have restarted it (yes, Phil, sometimes a restart DOES solve the problem ;-) ) If it is still sending out malformed XML I would be surprised, since it isn't breaking the Perl parsers...??? M On Thu, 2004-12-16 at 11:23, Paul Gordon wrote: > Hi everyone, > > MOBY Central code seems to have broken CentralImpl.java. The > returned object after a findService call is not well-formed XML, so Axis > doesn't let you get very far with debugging. I telneted to port 80 on > MOBY Central and POSTed a hand-crafted findService request. You can see > the input and output below, but the gist of it is that the Perl parser > of the MOBY Central server seems to switch a string for a hash reference > somewhere internally while handling the SOAP payload. I think this is a > bug in the server-side Perl. Are these errors due to the server code > transition currently taking place? > > A second issue is that the MOBY Central Apache appends its 500 Error > page to the SOAP message, making it an invalid XML document. Therefore > the real error never propagates to the client, but rather a parsing > error ooccurs. > > Regards, > > Paul > > -------------------------------------- > > Input to mobycentral.cbr.nrc.ca:80 > > POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 > Content-length: 840 > > > xmlns:soap="http://www.w3.org/2001/06/soap-envelope" > soap:encodingStyle="http://www.w3.org/2001/06/soap-encoding"> > > > > > xmlns="http://mobycentral.cbr.nrc.ca/MOBY/Central"> > > > Object > GO > > > > > > > > moby > > 1 > 1 > 0 > > > > > > > > I get the following error returned: > > HTTP/1.1 500 Internal Server Error > Date: Thu, 16 Dec 2004 19:11:59 GMT > Server: Apache/1.3.29 (Unix) mod_perl/1.29 > SOAPServer: SOAP::Lite/Perl/0.60 > Content-Length: 626 > Connection: close > Content-Type: text/xml; charset=utf-8 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://www.w3.org/2001/06/soap-encoding" > xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://www.w3.org/2001/06/soap-encoding">SOAP-ENV:ServerEntity: > line 1: error: Start tag expected, '<' not found > HASH(0x16a76a0) > ^ > at /usr/local/lib/perl5/site_perl/5.8.0/MOBY/Central.pm line 2277 > HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > > 500 Internal Server Error > >

Internal Server Error

> The server encountered an internal error or > misconfiguration and was unable to complete > your request.

> Please contact the server administrator, > markw at illuminae.com and inform them of the time the error occurred, > and anything you might have done that may have > caused the error.

> More information about this error may be available > in the server error log.

>


>
Apache/1.3.29 Server at mobycentral.cbr.nrc.ca Port 80
> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From gordonp at cbr.nrc.ca Thu Dec 16 15:22:43 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Thu, 16 Dec 2004 13:22:43 -0700 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> Message-ID: <41C1EE93.1080903@cbr.nrc.ca> Nope, using the main server and it's still broken. There must be something about the way Perl sets up a SOAP client request that the server Perl parser is expecting, but Axis does not provide. The problem is not (primarily) that malformed XML is sent back from the server, but that it does not properly read the input request XML (instead of a string it tries to parse a hash ref, probably an object handle, at MOBY::Central.pm line 2277). This may in fact be a separate issue from the CentralImpl.java problem, but I can't tell until the response is valid XML (i.e. the default Apache 500 error page is removed from the response). Mark Wilkinson wrote: >Hi Paul, > >Are you certain that it is still malformed? I think we fixed that >problem this morning. > >... oh.... wait... it may be that you are hitting the test server. Try >it again now that I have restarted it (yes, Phil, sometimes a restart >DOES solve the problem ;-) ) > >If it is still sending out malformed XML I would be surprised, since it >isn't breaking the Perl parsers...??? > > From mwilkinson at mrl.ubc.ca Thu Dec 16 15:55:55 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 12:55:55 -0800 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <41C1EE93.1080903@cbr.nrc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> <41C1EE93.1080903@cbr.nrc.ca> Message-ID: <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> Can you send me the message that it is choking on? (i.e. the on-the-wire XML). I'll send it directly and follow what's happening in trace mode. M On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > Nope, using the main server and it's still broken. There must be > something about the way Perl sets up a SOAP client request that the > server Perl parser is expecting, but Axis does not provide. The problem > is not (primarily) that malformed XML is sent back from the server, but > that it does not properly read the input request XML (instead of a > string it tries to parse a hash ref, probably an object handle, at > MOBY::Central.pm line 2277). > > This may in fact be a separate issue from the CentralImpl.java problem, > but I can't tell until the response is valid XML (i.e. the default > Apache 500 error page is removed from the response). > > Mark Wilkinson wrote: > > >Hi Paul, > > > >Are you certain that it is still malformed? I think we fixed that > >problem this morning. > > > >... oh.... wait... it may be that you are hitting the test server. Try > >it again now that I have restarted it (yes, Phil, sometimes a restart > >DOES solve the problem ;-) ) > > > >If it is still sending out malformed XML I would be surprised, since it > >isn't breaking the Perl parsers...??? > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Thu Dec 16 16:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 13:03:40 -0800 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> <41C1EE93.1080903@cbr.nrc.ca> <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> Message-ID: <1103231020.8319.160.camel@mobycentral.icapture.ubc.ca> The strange thing is that the error you are reporting is not appearing in the server logs...? Are you getting back a partial message, or is it a 500 error? M On Thu, 2004-12-16 at 12:55, Mark Wilkinson wrote: > Can you send me the message that it is choking on? (i.e. the > on-the-wire XML). I'll send it directly and follow what's happening in > trace mode. > > M > > > On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > > Nope, using the main server and it's still broken. There must be > > something about the way Perl sets up a SOAP client request that the > > server Perl parser is expecting, but Axis does not provide. The problem > > is not (primarily) that malformed XML is sent back from the server, but > > that it does not properly read the input request XML (instead of a > > string it tries to parse a hash ref, probably an object handle, at > > MOBY::Central.pm line 2277). > > > > This may in fact be a separate issue from the CentralImpl.java problem, > > but I can't tell until the response is valid XML (i.e. the default > > Apache 500 error page is removed from the response). > > > > Mark Wilkinson wrote: > > > > >Hi Paul, > > > > > >Are you certain that it is still malformed? I think we fixed that > > >problem this morning. > > > > > >... oh.... wait... it may be that you are hitting the test server. Try > > >it again now that I have restarted it (yes, Phil, sometimes a restart > > >DOES solve the problem ;-) ) > > > > > >If it is still sending out malformed XML I would be surprised, since it > > >isn't breaking the Perl parsers...??? > > > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From opushneva at yahoo.ca Fri Dec 17 13:40:23 2004 From: opushneva at yahoo.ca (Nina Opushneva) Date: Fri, 17 Dec 2004 10:40:23 -0800 (PST) Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103231020.8319.160.camel@mobycentral.icapture.ubc.ca> Message-ID: <20041217184023.89111.qmail@web60907.mail.yahoo.com> Hi Mark, Do you have the highest log level on the Apache server? Maybe it's the problem you have not report about the error. Nina --- Mark Wilkinson wrote: > The strange thing is that the error you are > reporting is not appearing > in the server logs...? Are you getting back a > partial message, or is it > a 500 error? > > M > > > On Thu, 2004-12-16 at 12:55, Mark Wilkinson wrote: > > Can you send me the message that it is choking on? > (i.e. the > > on-the-wire XML). I'll send it directly and > follow what's happening in > > trace mode. > > > > M > > > > > > On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > > > Nope, using the main server and it's still > broken. There must be > > > something about the way Perl sets up a SOAP > client request that the > > > server Perl parser is expecting, but Axis does > not provide. The problem > > > is not (primarily) that malformed XML is sent > back from the server, but > > > that it does not properly read the input request > XML (instead of a > > > string it tries to parse a hash ref, probably an > object handle, at > > > MOBY::Central.pm line 2277). > > > > > > This may in fact be a separate issue from the > CentralImpl.java problem, > > > but I can't tell until the response is valid XML > (i.e. the default > > > Apache 500 error page is removed from the > response). > > > > > > Mark Wilkinson wrote: > > > > > > >Hi Paul, > > > > > > > >Are you certain that it is still malformed? I > think we fixed that > > > >problem this morning. > > > > > > > >... oh.... wait... it may be that you are > hitting the test server. Try > > > >it again now that I have restarted it (yes, > Phil, sometimes a restart > > > >DOES solve the problem ;-) ) > > > > > > > >If it is still sending out malformed XML I > would be surprised, since it > > > >isn't breaking the Perl parsers...??? > > > > > > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Assistant Professor (Bioinformatics) > Dept. Medical Genetics, UBC, Canada > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From wong.yan at netcourrier.com Thu Dec 2 11:39:56 2004 From: wong.yan at netcourrier.com (wong.yan at netcourrier.com) Date: Thu, 2 Dec 2004 11:39:56 CET Subject: [MOBY-dev] question about the bioMoby python API Message-ID: one other solution is to put a type attribute on the body tag: the CORRECT message should be: your MobyContent in XML ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) From mark.fiers at wur.nl Thu Dec 2 13:19:59 2004 From: mark.fiers at wur.nl (Mark Fiers) Date: Thu, 02 Dec 2004 14:19:59 +0100 Subject: [MOBY-dev] question about the bioMoby python API In-Reply-To: References: Message-ID: <41AF167F.10001@wur.nl> wong.yan at netcourrier.com wrote: >one other solution is to put a type attribute on the body tag: > > But, if i am not mistaking, that would then have to be done by the people running http://mobycentral.cbr.nrc.ca/cgi-bin/gbrowse_moby since this site generates the ?'faulty'? body tag. (is it faulty? or is it still a valid soap call? Would a workaround be to edit the zsi code to default to a string if it doesn't find a xsi:type attribute? Or would that cause different problems? Mark >the CORRECT message should be: >your MobyContent in XML > > >------------------------------------------------------------- >NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... >Web/Wap : www.netcourrier.com >T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) >Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From wong.yan at netcourrier.com Thu Dec 2 21:13:47 2004 From: wong.yan at netcourrier.com (wong.yan at netcourrier.com) Date: Thu, 2 Dec 2004 21:13:47 CET Subject: [MOBY-dev] question about the bioMoby python API Message-ID: at my level, I believe it is an error, because the tag represent an object with a string inside (so what's the use of the body tag??). However, the SOAP call is still valid (so I work on a workaround for it). A work around on the ZSI patch will surely solve this issue, I am working it but at little speed... look at the file ZSI-1.5.0-patched/ZSI/TC.py: at the line: 254: if len(_child_elements(elt)) == 0: raise EvaluateException("Any cannot parse untyped element", ps.Backtrace(elt)) maybe a "return elt" (elt as a string) instead of "raise Exception etc.." should be sufficient... however, the Body is followed by the <[CDATA tag, this tag should be dropped in order to treat the MobyContent There may be another solution, define a class call Body but ZSI, the technique is described in the ZSI documentation page but the example with the "from ZSI import Path" doesn't work as the Path file is inexistant and make the script fail. link to the documentation of ZSI http://pywebsvcs.sourceforge.net/zsi.html see chapter 2.2.2 for defining a class for ZSI. ------------------------------------------------------------- NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar... Web/Wap : www.netcourrier.com T?l?phone/Fax : 08 92 69 00 21 (0,34 ? TTC/min) Minitel: 3615 NETCOURRIER (0,16 ? TTC/min) From mwilkinson at mobile.rogers.com Fri Dec 3 13:57:10 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 08:57:10 -0500 Subject: [MOBY-dev] Test request Message-ID: <200412031355.iB3DtlKr006219@portal.open-bio.org> Hi everyone, Can a few of you test mobycentral to see if it works for you? It is working for me (in my hotel room), but not for Rebecca nor Martin... I'm wondering if it is the connection between europe and here? M !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Fri Dec 3 18:05:14 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 13:05:14 -0500 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031804.iB3I47Kr008138@portal.open-bio.org> I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) Can our European partners keep an eye on it and let me know when it comes back up? Thanks! M !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From beatrice at arabidopsis.info Fri Dec 3 18:16:21 2004 From: beatrice at arabidopsis.info (Beatrice Schildknecht) Date: Fri, 03 Dec 2004 18:16:21 +0000 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> References: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: <41B0AD75.3060400@arabidopsis.info> I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From beatrice at arabidopsis.info Fri Dec 3 18:16:21 2004 From: beatrice at arabidopsis.info (Beatrice Schildknecht) Date: Fri, 03 Dec 2004 18:16:21 +0000 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> References: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: <41B0AD75.3060400@arabidopsis.info> I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From mwilkinson at mobile.rogers.com Fri Dec 3 18:18:54 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 13:18:54 -0500 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031818.iB3IIkKr008258@portal.open-bio.org> Ha! So Beatrice does live on! You should have stayed silent - now I will chase you down to fix your broken services ;-) M -----Original Message----- From: Beatrice Schildknecht Date: Fri, 03 Dec 2004 18:16:21 To:mwilkinson , Core developer announcements Cc:Moby-dev at open-bio.org Subject: Re: [MOBY-dev] It appears to be a European problem... I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From mwilkinson at mobile.rogers.com Fri Dec 3 18:18:54 2004 From: mwilkinson at mobile.rogers.com (mwilkinson) Date: Fri, 3 Dec 2004 13:18:54 -0500 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <200412031818.iB3IIlKr008262@portal.open-bio.org> Ha! So Beatrice does live on! You should have stayed silent - now I will chase you down to fix your broken services ;-) M -----Original Message----- From: Beatrice Schildknecht Date: Fri, 03 Dec 2004 18:16:21 To:mwilkinson , Core developer announcements Cc:Moby-dev at open-bio.org Subject: Re: [MOBY-dev] It appears to be a European problem... I am now able to connect! mwilkinson wrote: >I was able to connect from Halifax, and now from the Toronto airport, and Nina can connect from Vancouver. However, all reports from Europe are failing...?? > >I'll check with CBR and see if they have somehow configured their firewall differently (they were working on it yesterday) - it may be that they have an evil plan to keep Europe in the dark ;-) > >Can our European partners keep an eye on it and let me know when it comes back up? > >Thanks! > >M > >!!!!!!!!!!!!!!!! >To respond to this message you MUST send your response to (note new address!) > >markw_mobile2 at illuminae dot com > >Responses to the reply-to address go directly to trash! >!!!!!!!!!!!!!!!!!!!!!!!!!!!! >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > -- Nottingham Arabidopsis Stock Centre School of Biosciences Plant Science Division University of Nottingham Sutton Bonington Campus Loughborough LE12 5RD Tel: +44 115 951 3091 Catalogue: http://arabidopsis.info Affymetrix: http://affy.arabidopsis.info Genomics: http://atensembl.arabidopsis.info/ This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev !!!!!!!!!!!!!!!! To respond to this message you MUST send your response to (note new address!) markw_mobile2 at illuminae dot com Responses to the reply-to address go directly to trash! !!!!!!!!!!!!!!!!!!!!!!!!!!!! From senger at ebi.ac.uk Fri Dec 3 18:45:16 2004 From: senger at ebi.ac.uk (Martin Senger) Date: Fri, 3 Dec 2004 18:45:16 +0000 (GMT) Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412031804.iB3I47Kr008138@portal.open-bio.org> Message-ID: > Can our European partners keep an eye on it and let me know when it comes back up? > Well, England is back in the bussiness: [senger at localhost jMoby]$ build/run/run-testing-central retrieveServiceNames OK retrieveServiceProviders OK retrieveServiceTypes OK retrieveNamespaces OK retrieveObjectNames OK registerServiceType OK registerNamespace - 1 OK registerNamespace - 2 OK registerDataType - 1 OK registerDataType - 3 OK registerDataType - 2 OK getDataTypeDefinition - 2 OK registerService OK deregisterService OK deregisterDataType - 2 OK deregisterDataType - 3 OK deregisterDataType - 1 OK deregisterNamespace - 2 OK deregisterNamespace - 1 OK deregisterServiceType OK Thanks, Martin -- Martin Senger EMBL Outstation - Hinxton Senger at EBI.ac.uk European Bioinformatics Institute Phone: (+44) 1223 494636 Wellcome Trust Genome Campus (Switchboard: 494444) Hinxton Fax : (+44) 1223 494468 Cambridge CB10 1SD United Kingdom http://industry.ebi.ac.uk/~senger From duncan.hull at cs.man.ac.uk Tue Dec 7 09:11:59 2004 From: duncan.hull at cs.man.ac.uk (Duncan Hull) Date: Tue, 07 Dec 2004 09:11:59 +0000 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: References: Message-ID: <41B573DF.50501@cs.man.ac.uk> Martin Senger wrote: > Well, England is back in the bussiness: > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 From d.haase at gsf.de Tue Dec 7 09:43:16 2004 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 7 Dec 2004 10:43:16 +0100 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <41B573DF.50501@cs.man.ac.uk> References: <41B573DF.50501@cs.man.ac.uk> Message-ID: <200412071043.16612.d.haase@gsf.de> On Tuesday 07 December 2004 10:11, Duncan Hull wrote: > Martin Senger wrote: > > Well, England is back in the bussiness: > > > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, > which was working fine last night. Does anyone else in Europe have the > same problem? Yep, Germany is locked out as well. It went somehow in the early morning (~8am MET), but veeeeryyyy slow... Now it's completely gone :-( dirk From m.rouard at cgiar.org Tue Dec 7 09:56:15 2004 From: m.rouard at cgiar.org (Rouard, Mathieu (INIBAP - Montpellier)) Date: Tue, 07 Dec 2004 01:56:15 -0800 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <31AB896A0E7ED211BFBE0008C7283D13F936B3@inibapnt1.inibap.org> Hi Duncan, I have also some trouble in france today . I cannot connect to mobycentral. regards, mathieu -- Mathieu Rouard IPGRI-INIBAP < www.inibap.org > Parc Scientifique Agropolis II 34397 Montpellier - Cedex 5 - France Tel: +33 (0)467 61 13 02 Fax: +33 (0)467 61 03 34 -----Original Message----- From: Duncan Hull [mailto:duncan.hull at cs.man.ac.uk] Sent: mardi 7 d?cembre 2004 10:12 Cc: Moby-dev at open-bio.org; Mark Wilkinson Subject: Re: [MOBY-dev] It appears to be a European problem... Martin Senger wrote: > Well, England is back in the bussiness: > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From m.rouard at cgiar.org Tue Dec 7 09:56:15 2004 From: m.rouard at cgiar.org (Rouard, Mathieu (INIBAP - Montpellier)) Date: Tue, 07 Dec 2004 01:56:15 -0800 Subject: [MOBY-dev] It appears to be a European problem... Message-ID: <31AB896A0E7ED211BFBE0008C7283D13F936B3@inibapnt1.inibap.org> Hi Duncan, I have also some trouble in france today . I cannot connect to mobycentral. regards, mathieu -- Mathieu Rouard IPGRI-INIBAP < www.inibap.org > Parc Scientifique Agropolis II 34397 Montpellier - Cedex 5 - France Tel: +33 (0)467 61 13 02 Fax: +33 (0)467 61 03 34 -----Original Message----- From: Duncan Hull [mailto:duncan.hull at cs.man.ac.uk] Sent: mardi 7 d?cembre 2004 10:12 Cc: Moby-dev at open-bio.org; Mark Wilkinson Subject: Re: [MOBY-dev] It appears to be a European problem... Martin Senger wrote: > Well, England is back in the bussiness: > >[senger at localhost jMoby]$ build/run/run-testing-central > > I'm having trouble running mobycentral from Martins latest jMoby client, which was working fine last night. Does anyone else in Europe have the same problem? Duncan -- Duncan Hull http://www.cs.man.ac.uk/~hulld/ Phone: +44 (0) 161 275 0677 _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From d.haase at gsf.de Tue Dec 7 09:56:02 2004 From: d.haase at gsf.de (Dirk Haase) Date: Tue, 7 Dec 2004 10:56:02 +0100 Subject: [MOBY-dev] It appears to be a European problem... In-Reply-To: <200412071043.16612.d.haase@gsf.de> References: <41B573DF.50501@cs.man.ac.uk> <200412071043.16612.d.haase@gsf.de> Message-ID: <200412071056.02072.d.haase@gsf.de> On Tuesday 07 December 2004 10:43, Dirk Haase wrote: > On Tuesday 07 December 2004 10:11, Duncan Hull wrote: > > Martin Senger wrote: > > > Well, England is back in the bussiness: > > > > > >[senger at localhost jMoby]$ build/run/run-testing-central > > > > I'm having trouble running mobycentral from Martins latest jMoby client, > > which was working fine last night. Does anyone else in Europe have the > > same problem? > > Yep, Germany is locked out as well. It went somehow in the early morning > (~8am MET), but veeeeryyyy slow... Now it's completely gone :-( ... and _now_ it's ok again. Thanks to whoever... From mwilkinson at mrl.ubc.ca Tue Dec 7 17:21:02 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 07 Dec 2004 09:21:02 -0800 Subject: [MOBY-dev] [Fwd: [personal] Re: Intermittent loss of MOBY from Europe] Message-ID: <1102440061.16721.22.camel@mobycentral.icapture.ubc.ca> Hi all, Since your reports are generally coming in while I am sleeping and the problem is fixed by the time I wake up, can I ask you to do these tests next time you find that you cannot connect to MOBY Central? It's happened a few times in the past two weeks, and I'd like to know what the source of the problem is. thanks! M > Hi Mark, > > All of our tests show that the Moby service is reachable via Europe. > Next time you suspect connectivity problems, please go to: > > www.traceroute.org > > and try a few tests from the various links in Europe to see where the > problem lies. Then, if you can send us the output from your tests, we > should be able to determine if the problem lies in our network or > externally. Most of the links on this site have options to traceroute to > an IP (others have ping and other services available). -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From ywong at infobiogen.fr Wed Dec 8 16:17:22 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Wed, 08 Dec 2004 17:17:22 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: <41B72912.6030702@infobiogen.fr> I've solved the problem and posted corrections to the CVS. See changelog for listed modifications. Here are the following steps to do to update your bioMoby Python server API: In your bioMoby python package directory: -First update your ZSI library with the ZSI library provided by this package: cd packages tar jxvf ZSI-1.5.0-patched-2 cd ZSI-1.5.0-patched-2 python setup.py install (with your fancy options if you have) -Update your bioMoby Python library python setup.py install (with options) -Update your scripts by applying the rules: however, you'll have to change some things in your script: BEFORE: from ZSI import dispatch dispatch.AsCGI() NOW: from ZSI import dispatch from bioMoby.webservice import TCBioMoby dispatch.AsCGI(typesmodule=TCBioMoby) or with mod_python: dispatch.AsHandler(modules=myModule,), request=req, typesmodule=TCBioMoby) TCBioMoby contains a class that serialize/deserialize the content inside the tag Body into a MobyContent Object. This will allow a Python webservice to deal with gbrowse_moby. From mwilkinson at mrl.ubc.ca Wed Dec 8 16:54:01 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 08 Dec 2004 08:54:01 -0800 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > This will allow a Python webservice to deal with gbrowse_moby. Does gbrowse_moby send incorrectly formatted messages? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Wed Dec 8 16:54:01 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Wed, 08 Dec 2004 08:54:01 -0800 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > This will allow a Python webservice to deal with gbrowse_moby. Does gbrowse_moby send incorrectly formatted messages? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From ywong at infobiogen.fr Wed Dec 8 17:05:53 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Wed, 08 Dec 2004 18:05:53 +0100 Subject: [moby] [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: <41B72912.6030702@infobiogen.fr> <1102524841.18113.65.camel@mobycentral.icapture.ubc.ca> Message-ID: <41B73471.8020701@infobiogen.fr> AFAIK no, it doesn't. It is just a matter of mapping between XML objects and Python objects. As I have never used gbrowse_moby to test my services, I didn't know the MobyContent object was included in a body tag. My soap call send the MobyContent inside a string object: MobyContent Mark Wilkinson wrote: >On Wed, 2004-12-08 at 08:17, Yan Wong wrote: > > > > >>This will allow a Python webservice to deal with gbrowse_moby. >> >> > > >Does gbrowse_moby send incorrectly formatted messages? > >M > > > > From mark.fiers at wur.nl Fri Dec 10 14:29:27 2004 From: mark.fiers at wur.nl (Mark Fiers) Date: Fri, 10 Dec 2004 15:29:27 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices In-Reply-To: <41B72912.6030702@infobiogen.fr> References: <41B72912.6030702@infobiogen.fr> Message-ID: <41B9B2C7.6090901@wur.nl> Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From paulien.adamse at wur.nl Fri Dec 10 15:13:52 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Fri, 10 Dec 2004 16:13:52 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: Now the Python API has been fixed I get some results with my service. Great! But the output is not what it should be. Anybody got an idea what is wrong with it? At the moment the "content" also contains the result, but it should be visible for Namespace and Id as well. The function is called getWAtDBIdByPOAcc The function can be called with namespace PO_acc id 9054 I could realy use some feedback. Thanks in advance (and have a nice weekend...) Paulien Adamse -----Original Message----- From: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark Sent: vrijdag 10 december 2004 15:29 To: Core developer announcements Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From paulien.adamse at wur.nl Fri Dec 10 15:17:26 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Fri, 10 Dec 2004 16:17:26 +0100 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: -----Original Message----- From: Adamse, Paulien Sent: vrijdag 10 december 2004 16:14 To: 'Core developer announcements' Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Now the Python API has been fixed I get some results with my service. Great! But the output is not what it should be. Anybody got an idea what is wrong with it? At the moment the "content" also contains the result, but it should be visible for Namespace and Id as well. The function is called getWAtDBIdByPOAcc The function can be called with namespace PO_acc id 9054 I could realy use some feedback. Thanks in advance (and have a nice weekend...) Paulien Adamse -----Original Message----- From: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark Sent: vrijdag 10 december 2004 15:29 To: Core developer announcements Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Thank you very much!!!!! It almost works. I had to make one small change (after some searching); The Body class you've written is identified by a getattr in the module in question. This does not work since the tag send by gbrowse_moby is in lowercase. I've worked aroud this by changing 'class Body:' to 'class body:'. (is it possible to define __getattr__() on module level??? That would be a nice way to circumvent this problem) Concerning Mark's question if gbrowse_moby sends incorrectly formatted messages? The tag is as far as I understand not a valid soap tag and apparantly also not part of bioMoby XML. So, I would say that it is still open for discussion, I'm not an expert on the subject. Cheers Mark Yan Wong wrote: > > I've solved the problem and posted corrections to the CVS. > > See changelog for listed modifications. > > Here are the following steps to do to update your bioMoby Python > server API: > > In your bioMoby python package directory: > > -First update your ZSI library with the ZSI library provided by this > package: > cd packages > tar jxvf ZSI-1.5.0-patched-2 > cd ZSI-1.5.0-patched-2 > python setup.py install (with your fancy options if you have) > > -Update your bioMoby Python library > python setup.py install (with options) > > -Update your scripts by applying the rules: > however, you'll have to change some things in your script: > > BEFORE: > > from ZSI import dispatch > dispatch.AsCGI() > > NOW: > > from ZSI import dispatch > from bioMoby.webservice import TCBioMoby > > dispatch.AsCGI(typesmodule=TCBioMoby) > > or with mod_python: > > dispatch.AsHandler(modules=myModule,), request=req, > typesmodule=TCBioMoby) > > TCBioMoby contains a class that serialize/deserialize the content > inside the tag Body into a MobyContent Object. > > This will allow a Python webservice to deal with gbrowse_moby. > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From markw at illuminae.com Sat Dec 11 17:38:57 2004 From: markw at illuminae.com (Mark Wilkinson) Date: Sat, 11 Dec 2004 09:38:57 -0800 Subject: [MOBY-dev] A few new tools and updates Message-ID: <41BB30B1.8040105@illuminae.com> Hi all, Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: 1) Eddie has finished writing applets that help in the construction of new tools for creating objects,service types, and registering new service instances. Try them at: http://mobycentral.cbr.nrc.ca/applets (note that this is operating on the "live" database) 2) For a variety of reasons we've decided to change the structure of the Service Instance RDF. As such, I have temporarily switched the deregisterService function back 'on' in MOBY Central. You can deregister services as before using the API. 3) Once we have a good RDF generator, we will ask you again to retrieve the RDF of your services and we'll switch Nina's agent on. I'll then switch the deregisterService function 'off' again. Cheers all! Mark P.S. I'm planning to host the next (possibly last, depending on funding...) MOBY developers meeting in Vancouver in early May, 2005. Does anyone know of other conferences going on that we should avoid conflicting with? From ywong at infobiogen.fr Mon Dec 13 09:43:46 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon, 13 Dec 2004 10:43:46 +0100 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: Message-ID: <41BD6452.7090105@infobiogen.fr> You should have: -Output query name should be the same as Input query name: (Input : I have 'query1' as name for the query and I get '9054'?) -You seems to send a collection of identifiers, so you should return a collection of objects. With the Python API, just put your set of objects in a tuple: ('collectionName' , [object1, object2, object3, etc..]) the mobyContent will serialize the collection into this: -you return an object with namespace=WatDB inside the content. maybe is it better to put it in a cross reference: o=MobyObject(namespace='PO_acc', id='118') o._cross=[MobyObject(namespace='WatDB', id='118'] ( don' forget the [] because it is a set of objects) or use the MobyXref object to build a Xref object (defined in the Moby-s v0.8 API) from bioMoby import MobyXref xref=MobyXref("EMBL","X1112345", "www.illuminae.com","getEMBLRecord", "IEA", transform") see help(MobyXref) for details. or you want to return an object with WatDB namespace and id: o=MobyObject(namespace='WatDB', id='118') In all case, you must register WatDB as a namespace in the bioMoby directory: >>> from bioMoby import Namespace >>> watdb=Namespace(namespaceType="WatDB", contact="contact at host.domain", authURI="host.domain", description=" a small description of this object") If you want to register on another central than bioMoby: >>> from bioMoby import Central >>> newCentral=Central(url="URL_of_another_bioMoby_directory", ns="http://another_namespace") (see help(Central) for the other instanciation parameters) >>> watdb.central=newCentral and then register your new object: >>> result=watdb.register() and see if it is successful: >>> print result Adamse, Paulien wrote: >-----Original Message----- >From: Adamse, Paulien >Sent: vrijdag 10 december 2004 16:14 >To: 'Core developer announcements' >Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Now the Python API has been fixed I get some results with my service. >Great! But the output is not what it should be. Anybody got an idea what >is wrong with it? At the moment the "content" also contains the result, >but it should be visible for Namespace and Id as well. > >The function is called getWAtDBIdByPOAcc >The function can be called with namespace PO_acc id 9054 > >I could realy use some feedback. > >Thanks in advance >(and have a nice weekend...) > > >Paulien Adamse > >-----Original Message----- >From: moby-dev-bounces at portal.open-bio.org >[mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark >Sent: vrijdag 10 december 2004 15:29 >To: Core developer announcements >Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Thank you very much!!!!! > >It almost works. I had to make one small change (after some searching); >The Body class you've written is identified by a getattr in the module >in question. This does not work since the tag send by >gbrowse_moby is in lowercase. I've worked aroud this by changing 'class >Body:' to 'class body:'. (is it possible to define __getattr__() on >module level??? That would be a nice way to circumvent this problem) > >Concerning Mark's question if gbrowse_moby sends incorrectly formatted >messages? The tag is as far as I understand not a valid soap tag >and apparantly also not part of bioMoby XML. So, I would say that it is >still open for discussion, I'm not an expert on the subject. > >Cheers >Mark > > > > >Yan Wong wrote: > > > >>I've solved the problem and posted corrections to the CVS. >> >>See changelog for listed modifications. >> >>Here are the following steps to do to update your bioMoby Python >>server API: >> >>In your bioMoby python package directory: >> >>-First update your ZSI library with the ZSI library provided by this >>package: >>cd packages >>tar jxvf ZSI-1.5.0-patched-2 >>cd ZSI-1.5.0-patched-2 >>python setup.py install (with your fancy options if you have) >> >>-Update your bioMoby Python library >>python setup.py install (with options) >> >>-Update your scripts by applying the rules: >>however, you'll have to change some things in your script: >> >>BEFORE: >> >>from ZSI import dispatch >>dispatch.AsCGI() >> >>NOW: >> >>from ZSI import dispatch >>from bioMoby.webservice import TCBioMoby >> >>dispatch.AsCGI(typesmodule=TCBioMoby) >> >>or with mod_python: >> >>dispatch.AsHandler(modules=myModule,), request=req, >>typesmodule=TCBioMoby) >> >>TCBioMoby contains a class that serialize/deserialize the content >>inside the tag Body into a MobyContent Object. >> >>This will allow a Python webservice to deal with gbrowse_moby. >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > From ywong at infobiogen.fr Mon Dec 13 09:56:45 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon, 13 Dec 2004 10:56:45 +0100 Subject: [MOBY-dev] gbrowse_moby and bioMoby Python webservices References: <41B72912.6030702@infobiogen.fr> <41B9B2C7.6090901@wur.nl> Message-ID: <41BD675D.9000405@infobiogen.fr> The best way maybe it is to add another class in the TCBioMoby file: class body(Body): pass but then when you return the MobyContent to the client you should add: from bioMoby.webservice import TCBioMoby mobyContentToBeReturned=MobyContent(ResultsOfTheTreatments) mobyContentToBeReturned.typecode=TCBioMoby.body() #tell how ZSI should serialize mobyContentToBeReturned return mc Mark Fiers wrote: > Thank you very much!!!!! > > It almost works. I had to make one small change (after some > searching); The Body class you've written is identified by a getattr > in the module in question. This does not work since the tag > send by gbrowse_moby is in lowercase. I've worked aroud this by > changing 'class Body:' to 'class body:'. (is it possible to define > __getattr__() on module level??? That would be a nice way to > circumvent this problem) > > Concerning Mark's question if gbrowse_moby sends incorrectly formatted > messages? The tag is as far as I understand not a valid soap > tag and apparantly also not part of bioMoby XML. So, I would say that > it is still open for discussion, I'm not an expert on the subject. > > Cheers > Mark > > > > > Yan Wong wrote: > >> >> I've solved the problem and posted corrections to the CVS. >> >> See changelog for listed modifications. >> >> Here are the following steps to do to update your bioMoby Python >> server API: >> >> In your bioMoby python package directory: >> >> -First update your ZSI library with the ZSI library provided by this >> package: >> cd packages >> tar jxvf ZSI-1.5.0-patched-2 >> cd ZSI-1.5.0-patched-2 >> python setup.py install (with your fancy options if you have) >> >> -Update your bioMoby Python library >> python setup.py install (with options) >> >> -Update your scripts by applying the rules: >> however, you'll have to change some things in your script: >> >> BEFORE: >> >> from ZSI import dispatch >> dispatch.AsCGI() >> >> NOW: >> >> from ZSI import dispatch >> from bioMoby.webservice import TCBioMoby >> >> dispatch.AsCGI(typesmodule=TCBioMoby) >> >> or with mod_python: >> >> dispatch.AsHandler(modules=myModule,), request=req, >> typesmodule=TCBioMoby) >> >> TCBioMoby contains a class that serialize/deserialize the content >> inside the tag Body into a MobyContent Object. >> >> This will allow a Python webservice to deal with gbrowse_moby. >> >> >> _______________________________________________ >> MOBY-dev mailing list >> MOBY-dev at biomoby.org >> http://www.biomoby.org/mailman/listinfo/moby-dev >> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > From ywong at infobiogen.fr Mon Dec 13 13:43:46 2004 From: ywong at infobiogen.fr (Yan Wong) Date: Mon, 13 Dec 2004 14:43:46 +0100 Subject: [MOBY-dev] register recursive types Message-ID: <41BD9C92.6000108@infobiogen.fr> Is it possible to register recursive types in a bioMoby directory? I tried this: 1: AbstactNode ISA Object Nodelist ISA Object HAS AbstractNode Node ISA AbstractNode HASA NodeList are there other solutions? From rebecca.ernst at gsf.de Mon Dec 13 16:20:27 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Mon, 13 Dec 2004 17:20:27 +0100 Subject: [MOBY-dev] registration of services not possible yet In-Reply-To: <41BB30B1.8040105@illuminae.com> References: <41BB30B1.8040105@illuminae.com> Message-ID: <41BDC14B.1020804@gsf.de> Hi Mark! I just tried to deregister/register my services - it still tells me that I am not allowed to deregister a service that is registered having a RDF!! Rebecca Mark Wilkinson wrote: > Hi all, > > Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: > > 1) Eddie has finished writing applets that help in the construction > of new tools for creating objects,service types, and registering new > service instances. Try them at: > http://mobycentral.cbr.nrc.ca/applets (note that this is operating on > the "live" database) > > 2) For a variety of reasons we've decided to change the structure of > the Service Instance RDF. As such, I have temporarily switched the > deregisterService function back 'on' in MOBY Central. You can > deregister services as before using the API. > > 3) Once we have a good RDF generator, we will ask you again to > retrieve the RDF of your services and we'll switch Nina's agent on. > I'll then switch the deregisterService function 'off' again. > > Cheers all! > Mark > > P.S. I'm planning to host the next (possibly last, depending on > funding...) MOBY developers meeting in Vancouver in early May, 2005. > Does anyone know of other conferences going on that we should avoid > conflicting with? > _______________________________________________ > moby-l mailing list > moby-l at biomoby.org > http://biomoby.org/mailman/listinfo/moby-l > -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From mwilkinson at mrl.ubc.ca Mon Dec 13 17:53:21 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon, 13 Dec 2004 09:53:21 -0800 Subject: [MOBY-dev] Re: [moby] [MOBY-l] registration of services not possible yet In-Reply-To: <41BDC14B.1020804@gsf.de> References: <41BB30B1.8040105@illuminae.com> <41BDC14B.1020804@gsf.de> Message-ID: <1102960400.30331.26.camel@mobycentral.icapture.ubc.ca> Doh! I forgot to restart the server. Try now... M On Mon, 2004-12-13 at 08:20, Rebecca Ernst wrote: > Hi Mark! > > I just tried to deregister/register my services - it still tells me that > I am not allowed to deregister a service that is registered having a RDF!! > > Rebecca > > > > > Mark Wilkinson wrote: > > > Hi all, > > > > Here's an update of the latest goings-on with MOBY-S and MOBY-S tooling: > > > > 1) Eddie has finished writing applets that help in the construction > > of new tools for creating objects,service types, and registering new > > service instances. Try them at: > > http://mobycentral.cbr.nrc.ca/applets (note that this is operating on > > the "live" database) > > > > 2) For a variety of reasons we've decided to change the structure of > > the Service Instance RDF. As such, I have temporarily switched the > > deregisterService function back 'on' in MOBY Central. You can > > deregister services as before using the API. > > > > 3) Once we have a good RDF generator, we will ask you again to > > retrieve the RDF of your services and we'll switch Nina's agent on. > > I'll then switch the deregisterService function 'off' again. > > > > Cheers all! > > Mark > > > > P.S. I'm planning to host the next (possibly last, depending on > > funding...) MOBY developers meeting in Vancouver in early May, 2005. > > Does anyone know of other conferences going on that we should avoid > > conflicting with? > > _______________________________________________ > > moby-l mailing list > > moby-l at biomoby.org > > http://biomoby.org/mailman/listinfo/moby-l > > -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Mon Dec 13 18:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon, 13 Dec 2004 10:03:40 -0800 Subject: [moby] [MOBY-dev] register recursive types In-Reply-To: <41BD9C92.6000108@infobiogen.fr> References: <41BD9C92.6000108@infobiogen.fr> Message-ID: <1102961020.30331.38.camel@mobycentral.icapture.ubc.ca> I'm not quite sure what you are trying to achieve in that set of objects...?? M On Mon, 2004-12-13 at 05:43, Yan Wong wrote: > Is it possible to register recursive types in a bioMoby directory? > > I tried this: > > 1: > AbstactNode ISA Object > > Nodelist ISA Object HAS AbstractNode > > Node ISA AbstractNode HASA NodeList > > are there other solutions? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Mon Dec 13 18:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Mon, 13 Dec 2004 10:03:40 -0800 Subject: [moby] [MOBY-dev] register recursive types In-Reply-To: <41BD9C92.6000108@infobiogen.fr> References: <41BD9C92.6000108@infobiogen.fr> Message-ID: <1102961020.30331.38.camel@mobycentral.icapture.ubc.ca> I'm not quite sure what you are trying to achieve in that set of objects...?? M On Mon, 2004-12-13 at 05:43, Yan Wong wrote: > Is it possible to register recursive types in a bioMoby directory? > > I tried this: > > 1: > AbstactNode ISA Object > > Nodelist ISA Object HAS AbstractNode > > Node ISA AbstractNode HASA NodeList > > are there other solutions? > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From rebecca.ernst at gsf.de Tue Dec 14 09:01:37 2004 From: rebecca.ernst at gsf.de (Rebecca Ernst) Date: Tue, 14 Dec 2004 10:01:37 +0100 Subject: [MOBY-dev] service deregistration Message-ID: <41BEABF1.4050902@gsf.de> Hi Mark! the server restart didn't solve the problem. I still can only deregister services which are registered without RDF. Rebecca -- Rebecca Ernst MIPS, Inst. for Bioinformatics GSF Research Center for Environment and Health Ingolstaedter Landstr. 1 85764 Neuherberg fon: +49 89 3187 3583 email: Rebecca.Ernst at gsf.de From mwilkinson at mrl.ubc.ca Tue Dec 14 16:37:44 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 14 Dec 2004 08:37:44 -0800 Subject: [MOBY-dev] Re: [moby] [MOBY-l] service deregistration In-Reply-To: <41BEABF1.4050902@gsf.de> References: <41BEABF1.4050902@gsf.de> Message-ID: <1103042264.32326.34.camel@mobycentral.icapture.ubc.ca> Doh! DOH! You're right. The MOBY Central code is currently broken. Eddie is going to troubleshoot, and hopefully we'll have it up by the end of the day. In the meantime, MOBY Central is running on an older codebase, so almost everything is functioning properly. I'll restart the server again when the problem is identified. Sorry! M On Tue, 2004-12-14 at 01:01, Rebecca Ernst wrote: > Hi Mark! > > the server restart didn't solve the problem. I still can only deregister > services which are registered without RDF. > > Rebecca -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Wed Dec 15 00:45:52 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Tue, 14 Dec 2004 16:45:52 -0800 Subject: [MOBY-dev] For those who wanted tomcat on MOBY Central Message-ID: <1103071552.591.63.camel@mobycentral.icapture.ubc.ca> Hi all, I've had a few requests for a Tomcat installation on MOBY Central to deploy a variety of things there. Can I just check with those who have requested this whether you need Tomcat to be running through apache, or simply using its standalone server? M -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From paulien.adamse at wur.nl Wed Dec 15 07:49:30 2004 From: paulien.adamse at wur.nl (Adamse, Paulien) Date: Wed, 15 Dec 2004 08:49:30 +0100 Subject: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices Message-ID: Hi Yan Wong, Thanks for your detailed response. It should be possible to make it work now! Paulien PS I already registered the namespace WAtDB_Id. And put it in the content just to see some output. Don't intend to keep showing it there. Paulien Adamse Applied Bioinformatics Kamer 0.210 Tel. (4)76850 -----Original Message----- From: moby-dev-bounces at portal.open-bio.org [mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Yan Wong Sent: maandag 13 december 2004 10:44 To: Core developer announcements Subject: Re: FW: [MOBY-dev] gbrowse_moby and bioMoby Python webservices You should have: -Output query name should be the same as Input query name: (Input : I have 'query1' as name for the query and I get '9054'?) -You seems to send a collection of identifiers, so you should return a collection of objects. With the Python API, just put your set of objects in a tuple: ('collectionName' , [object1, object2, object3, etc..]) the mobyContent will serialize the collection into this: -you return an object with namespace=WatDB inside the content. maybe is it better to put it in a cross reference: o=MobyObject(namespace='PO_acc', id='118') o._cross=[MobyObject(namespace='WatDB', id='118'] ( don' forget the [] because it is a set of objects) or use the MobyXref object to build a Xref object (defined in the Moby-s v0.8 API) from bioMoby import MobyXref xref=MobyXref("EMBL","X1112345", "www.illuminae.com","getEMBLRecord", "IEA", transform") see help(MobyXref) for details. or you want to return an object with WatDB namespace and id: o=MobyObject(namespace='WatDB', id='118') In all case, you must register WatDB as a namespace in the bioMoby directory: >>> from bioMoby import Namespace >>> watdb=Namespace(namespaceType="WatDB", contact="contact at host.domain", authURI="host.domain", description=" a small description of this object") If you want to register on another central than bioMoby: >>> from bioMoby import Central >>> newCentral=Central(url="URL_of_another_bioMoby_directory", ns="http://another_namespace") (see help(Central) for the other instanciation parameters) >>> watdb.central=newCentral and then register your new object: >>> result=watdb.register() and see if it is successful: >>> print result Adamse, Paulien wrote: >-----Original Message----- >From: Adamse, Paulien >Sent: vrijdag 10 december 2004 16:14 >To: 'Core developer announcements' >Subject: RE: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Now the Python API has been fixed I get some results with my service. >Great! But the output is not what it should be. Anybody got an idea >what is wrong with it? At the moment the "content" also contains the >result, but it should be visible for Namespace and Id as well. > >The function is called getWAtDBIdByPOAcc >The function can be called with namespace PO_acc id 9054 > >I could realy use some feedback. > >Thanks in advance >(and have a nice weekend...) > > >Paulien Adamse > >-----Original Message----- >From: moby-dev-bounces at portal.open-bio.org >[mailto:moby-dev-bounces at portal.open-bio.org] On Behalf Of Fiers, Mark >Sent: vrijdag 10 december 2004 15:29 >To: Core developer announcements >Subject: Re: [MOBY-dev] gbrowse_moby and bioMoby Python webservices > >Thank you very much!!!!! > >It almost works. I had to make one small change (after some searching); >The Body class you've written is identified by a getattr in the module >in question. This does not work since the tag send by >gbrowse_moby is in lowercase. I've worked aroud this by changing 'class >Body:' to 'class body:'. (is it possible to define __getattr__() on >module level??? That would be a nice way to circumvent this problem) > >Concerning Mark's question if gbrowse_moby sends incorrectly formatted >messages? The tag is as far as I understand not a valid soap tag >and apparantly also not part of bioMoby XML. So, I would say that it is >still open for discussion, I'm not an expert on the subject. > >Cheers >Mark > > > > >Yan Wong wrote: > > > >>I've solved the problem and posted corrections to the CVS. >> >>See changelog for listed modifications. >> >>Here are the following steps to do to update your bioMoby Python >>server API: >> >>In your bioMoby python package directory: >> >>-First update your ZSI library with the ZSI library provided by this >>package: >>cd packages >>tar jxvf ZSI-1.5.0-patched-2 >>cd ZSI-1.5.0-patched-2 >>python setup.py install (with your fancy options if you have) >> >>-Update your bioMoby Python library >>python setup.py install (with options) >> >>-Update your scripts by applying the rules: >>however, you'll have to change some things in your script: >> >>BEFORE: >> >>from ZSI import dispatch >>dispatch.AsCGI() >> >>NOW: >> >>from ZSI import dispatch >>from bioMoby.webservice import TCBioMoby >> >>dispatch.AsCGI(typesmodule=TCBioMoby) >> >>or with mod_python: >> >>dispatch.AsHandler(modules=myModule,), request=req, >>typesmodule=TCBioMoby) >> >>TCBioMoby contains a class that serialize/deserialize the content >>inside the tag Body into a MobyContent Object. >> >>This will allow a Python webservice to deal with gbrowse_moby. >> >> >>_______________________________________________ >>MOBY-dev mailing list >>MOBY-dev at biomoby.org >>http://www.biomoby.org/mailman/listinfo/moby-dev >> >> >> > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > >_______________________________________________ >MOBY-dev mailing list >MOBY-dev at biomoby.org >http://www.biomoby.org/mailman/listinfo/moby-dev > > > _______________________________________________ MOBY-dev mailing list MOBY-dev at biomoby.org http://www.biomoby.org/mailman/listinfo/moby-dev From mwilkinson at mrl.ubc.ca Thu Dec 16 16:30:52 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 08:30:52 -0800 Subject: [MOBY-dev] extensive updates Message-ID: <1103214652.8319.30.camel@mobycentral.icapture.ubc.ca> Hi all, Those of you running MOBY locally, using any of the MOBY::Client::* libraries, and/or running local copies of gbrowse_moby will need to do an update on *everything* to accommodate the new XML parsing libraries that we are now using. We replaced the XML parser in all core MOBY modules (both client and server side), the gbrowse_moby script itself, and in all of the gbrowse_moby renderers. No new configuration is required - just CVS update and install as usual. This doesn't give us any new functionality right now, but it does mean that we will soon be "safely" parsing XML, since the new library is namespace-aware (until now we have been relying on people using the moby: prefix to mean the same thing... eeek!) Cheers everyone! Mark -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From gordonp at cbr.nrc.ca Thu Dec 16 19:23:54 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Thu, 16 Dec 2004 12:23:54 -0700 Subject: [MOBY-dev] MOBY Central now breaks Java In-Reply-To: References: Message-ID: <41C1E0CA.4040307@cbr.nrc.ca> Hi everyone, MOBY Central code seems to have broken CentralImpl.java. The returned object after a findService call is not well-formed XML, so Axis doesn't let you get very far with debugging. I telneted to port 80 on MOBY Central and POSTed a hand-crafted findService request. You can see the input and output below, but the gist of it is that the Perl parser of the MOBY Central server seems to switch a string for a hash reference somewhere internally while handling the SOAP payload. I think this is a bug in the server-side Perl. Are these errors due to the server code transition currently taking place? A second issue is that the MOBY Central Apache appends its 500 Error page to the SOAP message, making it an invalid XML document. Therefore the real error never propagates to the client, but rather a parsing error ooccurs. Regards, Paul -------------------------------------- Input to mobycentral.cbr.nrc.ca:80 POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 Content-length: 840 Object GO moby 1 1 0 I get the following error returned: HTTP/1.1 500 Internal Server Error Date: Thu, 16 Dec 2004 19:11:59 GMT Server: Apache/1.3.29 (Unix) mod_perl/1.29 SOAPServer: SOAP::Lite/Perl/0.60 Content-Length: 626 Connection: close Content-Type: text/xml; charset=utf-8 SOAP-ENV:ServerEntity: line 1: error: Start tag expected, '<' not found HASH(0x16a76a0) ^ at /usr/local/lib/perl5/site_perl/5.8.0/MOBY/Central.pm line 2277 500 Internal Server Error

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, markw at illuminae.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.


Apache/1.3.29 Server at mobycentral.cbr.nrc.ca Port 80
From mwilkinson at mrl.ubc.ca Thu Dec 16 20:16:04 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 12:16:04 -0800 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <41C1E0CA.4040307@cbr.nrc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> Message-ID: <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> Hi Paul, Are you certain that it is still malformed? I think we fixed that problem this morning. ... oh.... wait... it may be that you are hitting the test server. Try it again now that I have restarted it (yes, Phil, sometimes a restart DOES solve the problem ;-) ) If it is still sending out malformed XML I would be surprised, since it isn't breaking the Perl parsers...??? M On Thu, 2004-12-16 at 11:23, Paul Gordon wrote: > Hi everyone, > > MOBY Central code seems to have broken CentralImpl.java. The > returned object after a findService call is not well-formed XML, so Axis > doesn't let you get very far with debugging. I telneted to port 80 on > MOBY Central and POSTed a hand-crafted findService request. You can see > the input and output below, but the gist of it is that the Perl parser > of the MOBY Central server seems to switch a string for a hash reference > somewhere internally while handling the SOAP payload. I think this is a > bug in the server-side Perl. Are these errors due to the server code > transition currently taking place? > > A second issue is that the MOBY Central Apache appends its 500 Error > page to the SOAP message, making it an invalid XML document. Therefore > the real error never propagates to the client, but rather a parsing > error ooccurs. > > Regards, > > Paul > > -------------------------------------- > > Input to mobycentral.cbr.nrc.ca:80 > > POST /cgi-bin/MOBY05/mobycentral.pl HTTP/1.0 > Content-length: 840 > > > xmlns:soap="http://www.w3.org/2001/06/soap-envelope" > soap:encodingStyle="http://www.w3.org/2001/06/soap-encoding"> > > > > > xmlns="http://mobycentral.cbr.nrc.ca/MOBY/Central"> > > > Object > GO > > > > > > > > moby > > 1 > 1 > 0 > > > > > > > > I get the following error returned: > > HTTP/1.1 500 Internal Server Error > Date: Thu, 16 Dec 2004 19:11:59 GMT > Server: Apache/1.3.29 (Unix) mod_perl/1.29 > SOAPServer: SOAP::Lite/Perl/0.60 > Content-Length: 626 > Connection: close > Content-Type: text/xml; charset=utf-8 > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:SOAP-ENC="http://www.w3.org/2001/06/soap-encoding" > xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > SOAP-ENV:encodingStyle="http://www.w3.org/2001/06/soap-encoding">SOAP-ENV:ServerEntity: > line 1: error: Start tag expected, '<' not found > HASH(0x16a76a0) > ^ > at /usr/local/lib/perl5/site_perl/5.8.0/MOBY/Central.pm line 2277 > HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > > 500 Internal Server Error > >

Internal Server Error

> The server encountered an internal error or > misconfiguration and was unable to complete > your request.

> Please contact the server administrator, > markw at illuminae.com and inform them of the time the error occurred, > and anything you might have done that may have > caused the error.

> More information about this error may be available > in the server error log.

>


>
Apache/1.3.29 Server at mobycentral.cbr.nrc.ca Port 80
> > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From gordonp at cbr.nrc.ca Thu Dec 16 20:22:43 2004 From: gordonp at cbr.nrc.ca (Paul Gordon) Date: Thu, 16 Dec 2004 13:22:43 -0700 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> Message-ID: <41C1EE93.1080903@cbr.nrc.ca> Nope, using the main server and it's still broken. There must be something about the way Perl sets up a SOAP client request that the server Perl parser is expecting, but Axis does not provide. The problem is not (primarily) that malformed XML is sent back from the server, but that it does not properly read the input request XML (instead of a string it tries to parse a hash ref, probably an object handle, at MOBY::Central.pm line 2277). This may in fact be a separate issue from the CentralImpl.java problem, but I can't tell until the response is valid XML (i.e. the default Apache 500 error page is removed from the response). Mark Wilkinson wrote: >Hi Paul, > >Are you certain that it is still malformed? I think we fixed that >problem this morning. > >... oh.... wait... it may be that you are hitting the test server. Try >it again now that I have restarted it (yes, Phil, sometimes a restart >DOES solve the problem ;-) ) > >If it is still sending out malformed XML I would be surprised, since it >isn't breaking the Perl parsers...??? > > From mwilkinson at mrl.ubc.ca Thu Dec 16 20:55:55 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 12:55:55 -0800 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <41C1EE93.1080903@cbr.nrc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> <41C1EE93.1080903@cbr.nrc.ca> Message-ID: <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> Can you send me the message that it is choking on? (i.e. the on-the-wire XML). I'll send it directly and follow what's happening in trace mode. M On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > Nope, using the main server and it's still broken. There must be > something about the way Perl sets up a SOAP client request that the > server Perl parser is expecting, but Axis does not provide. The problem > is not (primarily) that malformed XML is sent back from the server, but > that it does not properly read the input request XML (instead of a > string it tries to parse a hash ref, probably an object handle, at > MOBY::Central.pm line 2277). > > This may in fact be a separate issue from the CentralImpl.java problem, > but I can't tell until the response is valid XML (i.e. the default > Apache 500 error page is removed from the response). > > Mark Wilkinson wrote: > > >Hi Paul, > > > >Are you certain that it is still malformed? I think we fixed that > >problem this morning. > > > >... oh.... wait... it may be that you are hitting the test server. Try > >it again now that I have restarted it (yes, Phil, sometimes a restart > >DOES solve the problem ;-) ) > > > >If it is still sending out malformed XML I would be surprised, since it > >isn't breaking the Perl parsers...??? > > > > > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From mwilkinson at mrl.ubc.ca Thu Dec 16 21:03:40 2004 From: mwilkinson at mrl.ubc.ca (Mark Wilkinson) Date: Thu, 16 Dec 2004 13:03:40 -0800 Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> References: <41C1E0CA.4040307@cbr.nrc.ca> <1103228164.8319.143.camel@mobycentral.icapture.ubc.ca> <41C1EE93.1080903@cbr.nrc.ca> <1103230555.8319.151.camel@mobycentral.icapture.ubc.ca> Message-ID: <1103231020.8319.160.camel@mobycentral.icapture.ubc.ca> The strange thing is that the error you are reporting is not appearing in the server logs...? Are you getting back a partial message, or is it a 500 error? M On Thu, 2004-12-16 at 12:55, Mark Wilkinson wrote: > Can you send me the message that it is choking on? (i.e. the > on-the-wire XML). I'll send it directly and follow what's happening in > trace mode. > > M > > > On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > > Nope, using the main server and it's still broken. There must be > > something about the way Perl sets up a SOAP client request that the > > server Perl parser is expecting, but Axis does not provide. The problem > > is not (primarily) that malformed XML is sent back from the server, but > > that it does not properly read the input request XML (instead of a > > string it tries to parse a hash ref, probably an object handle, at > > MOBY::Central.pm line 2277). > > > > This may in fact be a separate issue from the CentralImpl.java problem, > > but I can't tell until the response is valid XML (i.e. the default > > Apache 500 error page is removed from the response). > > > > Mark Wilkinson wrote: > > > > >Hi Paul, > > > > > >Are you certain that it is still malformed? I think we fixed that > > >problem this morning. > > > > > >... oh.... wait... it may be that you are hitting the test server. Try > > >it again now that I have restarted it (yes, Phil, sometimes a restart > > >DOES solve the problem ;-) ) > > > > > >If it is still sending out malformed XML I would be surprised, since it > > >isn't breaking the Perl parsers...??? > > > > > > > > > > _______________________________________________ > > MOBY-dev mailing list > > MOBY-dev at biomoby.org > > http://www.biomoby.org/mailman/listinfo/moby-dev -- Mark Wilkinson Assistant Professor (Bioinformatics) Dept. Medical Genetics, UBC, Canada From opushneva at yahoo.ca Fri Dec 17 18:40:23 2004 From: opushneva at yahoo.ca (Nina Opushneva) Date: Fri, 17 Dec 2004 10:40:23 -0800 (PST) Subject: [moby] [MOBY-dev] MOBY Central now breaks Java In-Reply-To: <1103231020.8319.160.camel@mobycentral.icapture.ubc.ca> Message-ID: <20041217184023.89111.qmail@web60907.mail.yahoo.com> Hi Mark, Do you have the highest log level on the Apache server? Maybe it's the problem you have not report about the error. Nina --- Mark Wilkinson wrote: > The strange thing is that the error you are > reporting is not appearing > in the server logs...? Are you getting back a > partial message, or is it > a 500 error? > > M > > > On Thu, 2004-12-16 at 12:55, Mark Wilkinson wrote: > > Can you send me the message that it is choking on? > (i.e. the > > on-the-wire XML). I'll send it directly and > follow what's happening in > > trace mode. > > > > M > > > > > > On Thu, 2004-12-16 at 12:22, Paul Gordon wrote: > > > Nope, using the main server and it's still > broken. There must be > > > something about the way Perl sets up a SOAP > client request that the > > > server Perl parser is expecting, but Axis does > not provide. The problem > > > is not (primarily) that malformed XML is sent > back from the server, but > > > that it does not properly read the input request > XML (instead of a > > > string it tries to parse a hash ref, probably an > object handle, at > > > MOBY::Central.pm line 2277). > > > > > > This may in fact be a separate issue from the > CentralImpl.java problem, > > > but I can't tell until the response is valid XML > (i.e. the default > > > Apache 500 error page is removed from the > response). > > > > > > Mark Wilkinson wrote: > > > > > > >Hi Paul, > > > > > > > >Are you certain that it is still malformed? I > think we fixed that > > > >problem this morning. > > > > > > > >... oh.... wait... it may be that you are > hitting the test server. Try > > > >it again now that I have restarted it (yes, > Phil, sometimes a restart > > > >DOES solve the problem ;-) ) > > > > > > > >If it is still sending out malformed XML I > would be surprised, since it > > > >isn't breaking the Perl parsers...??? > > > > > > > > > > > > > > _______________________________________________ > > > MOBY-dev mailing list > > > MOBY-dev at biomoby.org > > > http://www.biomoby.org/mailman/listinfo/moby-dev > -- > Mark Wilkinson > Assistant Professor (Bioinformatics) > Dept. Medical Genetics, UBC, Canada > > _______________________________________________ > MOBY-dev mailing list > MOBY-dev at biomoby.org > http://www.biomoby.org/mailman/listinfo/moby-dev > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com