plastic-devs Mailing List for PLASTIC (Page 8)
Brought to you by:
johndavidtaylor,
thomasboch
Menu
▾
▴
plastic-devs — Plastic Developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(15) |
Nov
(11) |
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
(110) |
Mar
(36) |
Apr
(55) |
May
(42) |
Jun
|
Jul
(42) |
Aug
(14) |
Sep
(34) |
Oct
(7) |
Nov
(35) |
Dec
(5) |
| 2007 |
Jan
(3) |
Feb
(5) |
Mar
(18) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(27) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John T. <jon...@gm...> - 2006-07-07 12:10:17
|
> > >>> Also, I suppose badly behaved apps might not choose to respond and then >>> the hub has to start making decisions... but then I thought I observed >>> that the hub unregistered eirik, if it returned "false" ? >>> >> It certainly shouldn't do that. >> > > I think the problem was a bad cast I was making: quick question just to > clarify.. the third arg to perform is always an array in xml/List in java? > > That's right. Anything appearing in the Java API as a List, is passed as an xml-rpc array. This is hidden away on http://plastic.sourceforge.net/coremessages.html under general information. John |
|
From: R H. <ric...@co...> - 2006-07-07 10:53:43
|
On Tue, 4 Jul 2006, Mark Taylor wrote: > On Tue, 4 Jul 2006, R Holbrey wrote: > >> I still see an admin role for the hub here (not popular, I know). It now >> see it would mean extra work and complexity, but hey, why write the code >> there when it can be done again and again in Java, c++, python.. ;-) > > hmmm... How about this for a less intrusive mechanism (based on the the idea of reference counting 'smart-pointers'): 1. An application registers an interesting votable with the hub, and its location is broadcast to other interested apps. 2. Other apps (if they are interested) load the table and tell the hub, which increases the hub's reference count by one (for each app). 3. If these apps signal 'not interested' or they unregister, the hub reference count falls to zero and the hub deletes the file (or notifies the originating or last 'interested' app to delete). --- This would at least, save some unnecessary copying, and might allow temp files to exist while downloading from elsewhere..? > >> Also, I suppose badly behaved apps might not choose to respond and then >> the hub has to start making decisions... but then I thought I observed >> that the hub unregistered eirik, if it returned "false" ? > > It certainly shouldn't do that. I think the problem was a bad cast I was making: quick question just to clarify.. the third arg to perform is always an array in xml/List in java? Richard |
|
From: R H. <ric...@co...> - 2006-07-04 13:32:14
|
On Tue, 4 Jul 2006, John Taylor wrote: > >> there when it can be done again and again in Java, c++, python.. ;-) >> >> Also, I suppose badly behaved apps might not choose to respond and then >> the hub has to start making decisions... but then I thought I observed >> that the hub unregistered eirik, if it returned "false" ? >> > Errr....if it does then that's a bug. It will unregister you if you > don't respond....it assumes that the app has died. > It shouldn't unregister you if you respond but say you couldn't load the > table. > John I'm not trying to cause trouble (honest!) but I can't now seem to get it to unregister either which way... probably I was doing something pretty bad, but there seems little point in trying to reproduce it. Richard |
|
From: John T. <jon...@gm...> - 2006-07-04 12:59:47
|
> there when it can be done again and again in Java, c++, python.. ;-) > > Also, I suppose badly behaved apps might not choose to respond and then > the hub has to start making decisions... but then I thought I observed > that the hub unregistered eirik, if it returned "false" ? > Errr....if it does then that's a bug. It will unregister you if you don't respond....it assumes that the app has died. It shouldn't unregister you if you respond but say you couldn't load the table. John > Richard > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plastic-devs mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/plastic-devs > > |
|
From: Mark T. <m.b...@br...> - 2006-07-04 12:41:20
|
On Tue, 4 Jul 2006, R Holbrey wrote: > I still see an admin role for the hub here (not popular, I know). It now > see it would mean extra work and complexity, but hey, why write the code > there when it can be done again and again in Java, c++, python.. ;-) hmmm... > Also, I suppose badly behaved apps might not choose to respond and then > the hub has to start making decisions... but then I thought I observed > that the hub unregistered eirik, if it returned "false" ? It certainly shouldn't do that. -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: R H. <ric...@co...> - 2006-07-04 12:33:16
|
On Tue, 4 Jul 2006, Mark Taylor wrote: > On Tue, 4 Jul 2006, R Holbrey wrote: > >>> To prevent this kind of confusion though, maybe there should be something >>> explicit in the message definition for loadURL which says that the URL is >>> only guaranteed to remain usable between when the message is sent and >>> when the receiver provides the return value (or possibly some other >>> policy we agree on). >>> >>> Mark >> >> Wouldn't work for me either now I think about it - I'm relying on a >> persistant copy of the file somewhere. I guess it's up to me to make a >> copy, but topcat etc could get very bored waiting for replies to come >> back. If you were sending to a specific receiver, might it be possible >> to transfer ownership? > > Not inconceivable, but it would start to make that message very messy, > especially since it may not be a temporary file, or a file at all > (may well be an http: type URL etc). To follow that route probably > the best thing would be to have the hub providing some service to do > the hard work - however, like John, I'm not very enthusiastic for the > hub to start broadening its portfolio like that. > > I appreciate there is a problem, though it's probably not possible to > solve it with complete reliability (staged SIAP tables etc). > If you really do need a persistent version of the table then probably > making a copy is the right thing to do, though it's not very elegant > since a broadcast might result in many listening applications making > (possibly unnecessary, if it's not a temporary file URL after all) > copies of the same data. However as far as response time for the > message goes I'd say it is reasonable for Eirik to take time to do > the copy before replying. An alternative hack, though it's getting > a bit OS-specific, is to get some sort of handle on the file which > will allow you to continue to access it even if it's deleted > (in Un*x you could make a hard link, or just keep a copy of the > open file handle). > > Mark I still see an admin role for the hub here (not popular, I know). It now see it would mean extra work and complexity, but hey, why write the code there when it can be done again and again in Java, c++, python.. ;-) Also, I suppose badly behaved apps might not choose to respond and then the hub has to start making decisions... but then I thought I observed that the hub unregistered eirik, if it returned "false" ? Richard |
|
From: Mark T. <m.b...@br...> - 2006-07-04 12:18:07
|
On Tue, 4 Jul 2006, R Holbrey wrote: > > To prevent this kind of confusion though, maybe there should be something > > explicit in the message definition for loadURL which says that the URL is > > only guaranteed to remain usable between when the message is sent and > > when the receiver provides the return value (or possibly some other > > policy we agree on). > > > > Mark > > Wouldn't work for me either now I think about it - I'm relying on a > persistant copy of the file somewhere. I guess it's up to me to make a > copy, but topcat etc could get very bored waiting for replies to come > back. If you were sending to a specific receiver, might it be possible > to transfer ownership? Not inconceivable, but it would start to make that message very messy, especially since it may not be a temporary file, or a file at all (may well be an http: type URL etc). To follow that route probably the best thing would be to have the hub providing some service to do the hard work - however, like John, I'm not very enthusiastic for the hub to start broadening its portfolio like that. I appreciate there is a problem, though it's probably not possible to solve it with complete reliability (staged SIAP tables etc). If you really do need a persistent version of the table then probably making a copy is the right thing to do, though it's not very elegant since a broadcast might result in many listening applications making (possibly unnecessary, if it's not a temporary file URL after all) copies of the same data. However as far as response time for the message goes I'd say it is reasonable for Eirik to take time to do the copy before replying. An alternative hack, though it's getting a bit OS-specific, is to get some sort of handle on the file which will allow you to continue to access it even if it's deleted (in Un*x you could make a hard link, or just keep a copy of the open file handle). Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: R H. <ric...@co...> - 2006-07-04 12:02:09
|
On Tue, 4 Jul 2006, Mark Taylor wrote: > On Tue, 4 Jul 2006, R Holbrey wrote: > >> On Tue, 4 Jul 2006, Mark Taylor wrote: >> >>> On Tue, 4 Jul 2006, B Walshe wrote: >>> >>>> Quoting Mark Taylor <m.b...@br...>: >>>> >>>> >>>>> my best guess for what's happening here is that TOPCAT is writing the >>>>> temporary file (in /tmp/plastic*.vot, as John says), but then deleting >>>>> it before Eirik has read it. What it does for a table broadcast/transmit is: >>>>> >>>>> 1. Write a VOTable representing the current state of the table to >>>>> be sent to a temporary file >>>>> 2. Send the loadFromURL message >>>>> 3. Wait for the response object from the hub describing which >>>>> listeners succeeded and which failed to load the table >>>>> 4. Delete the temporary file >>>>> >>>>> So you might well see what you are seeing if you are replying to the >>>>> loadFromUrl (returning a true/false error status) before you've actually >>>>> consumed the temporary file. >>>>> >>>>> Is that what you're doing? >>>>> >>>>> Mark >>>>> >>>> >>>> Yes, I think I might be sending the response before I load the table. I >>>> have my message handler and table loader running in separate threads. >>> >>> that would make sense then - hope it's not too difficult for you to >>> work round it. There's nothing in the message definition that says >>> how persistent that URL should be, but I like to clear it up quite >>> soon to prevent overuse of temporary disk space. If it's causing >>> problems which are difficult to solve for you or Richard as message >>> receivers I could reconsider how TOPCAT goes about this. >>> >>> Mark >>> >> >> apologies, since I wandered off to something else for a while... haven't >> tested it but I'm sure this is the same (threading issue) for me. It >> occurs to me though that unless all apps check all returning messages to a >> general broadcast, this could be messy. Perhaps file cleaning might be >> better placed in the hub... ? > > I don't think that makes sense, since as far as the hub knows the > URL sent in the loadURL message is just a string. The hub doesn't have > enough information to work out that it's the name of a temporary file > which needs to be deleted once it's no longer in use. It's only > likely to be the sending application which knows whether that's > the case or not. > > To prevent this kind of confusion though, maybe there should be something > explicit in the message definition for loadURL which says that the URL is > only guaranteed to remain usable between when the message is sent and > when the receiver provides the return value (or possibly some other > policy we agree on). > > Mark Wouldn't work for me either now I think about it - I'm relying on a persistant copy of the file somewhere. I guess it's up to me to make a copy, but topcat etc could get very bored waiting for replies to come back. If you were sending to a specific receiver, might it be possible to transfer ownership? Richard |
|
From: John T. <jon...@gm...> - 2006-07-04 11:49:28
|
R Holbrey wrote: > On Tue, 4 Jul 2006, Mark Taylor wrote: > > >> On Tue, 4 Jul 2006, B Walshe wrote: >> >> >>> Quoting Mark Taylor <m.b...@br...>: >>> >>> >>> >>>> my best guess for what's happening here is that TOPCAT is writing the >>>> temporary file (in /tmp/plastic*.vot, as John says), but then deleting >>>> it before Eirik has read it. What it does for a table broadcast/transmit is: >>>> >>>> 1. Write a VOTable representing the current state of the table to >>>> be sent to a temporary file >>>> 2. Send the loadFromURL message >>>> 3. Wait for the response object from the hub describing which >>>> listeners succeeded and which failed to load the table >>>> 4. Delete the temporary file >>>> >>>> So you might well see what you are seeing if you are replying to the >>>> loadFromUrl (returning a true/false error status) before you've actually >>>> consumed the temporary file. >>>> >>>> Is that what you're doing? >>>> >>>> Mark >>>> >>>> >>> Yes, I think I might be sending the response before I load the table. I >>> have my message handler and table loader running in separate threads. >>> >> that would make sense then - hope it's not too difficult for you to >> work round it. There's nothing in the message definition that says >> how persistent that URL should be, but I like to clear it up quite >> soon to prevent overuse of temporary disk space. If it's causing >> problems which are difficult to solve for you or Richard as message >> receivers I could reconsider how TOPCAT goes about this. >> >> Mark >> >> > > apologies, since I wandered off to something else for a while... haven't > tested it but I'm sure this is the same (threading issue) for me. It > occurs to me though that unless all apps check all returning messages to a > general broadcast, this could be messy. Perhaps file cleaning might be > better placed in the hub... ? > > Richard > > We've always worked on the principle that the hub shouldn't understand the messages, so it has no way of knowing which arguments apply to files that need cleaning up. That said, we could consider having the hub offer some kind of "create temporary file" service, but my instinct is against it...I don't see how we could get it to work (and anyway, it won't fix my example SIAP service issue). J |
|
From: Mark T. <m.b...@br...> - 2006-07-04 11:48:05
|
On Tue, 4 Jul 2006, R Holbrey wrote: > On Tue, 4 Jul 2006, Mark Taylor wrote: > > > On Tue, 4 Jul 2006, B Walshe wrote: > > > >> Quoting Mark Taylor <m.b...@br...>: > >> > >> > >>> my best guess for what's happening here is that TOPCAT is writing the > >>> temporary file (in /tmp/plastic*.vot, as John says), but then deleting > >>> it before Eirik has read it. What it does for a table broadcast/transmit is: > >>> > >>> 1. Write a VOTable representing the current state of the table to > >>> be sent to a temporary file > >>> 2. Send the loadFromURL message > >>> 3. Wait for the response object from the hub describing which > >>> listeners succeeded and which failed to load the table > >>> 4. Delete the temporary file > >>> > >>> So you might well see what you are seeing if you are replying to the > >>> loadFromUrl (returning a true/false error status) before you've actually > >>> consumed the temporary file. > >>> > >>> Is that what you're doing? > >>> > >>> Mark > >>> > >> > >> Yes, I think I might be sending the response before I load the table. I > >> have my message handler and table loader running in separate threads. > > > > that would make sense then - hope it's not too difficult for you to > > work round it. There's nothing in the message definition that says > > how persistent that URL should be, but I like to clear it up quite > > soon to prevent overuse of temporary disk space. If it's causing > > problems which are difficult to solve for you or Richard as message > > receivers I could reconsider how TOPCAT goes about this. > > > > Mark > > > > apologies, since I wandered off to something else for a while... haven't > tested it but I'm sure this is the same (threading issue) for me. It > occurs to me though that unless all apps check all returning messages to a > general broadcast, this could be messy. Perhaps file cleaning might be > better placed in the hub... ? I don't think that makes sense, since as far as the hub knows the URL sent in the loadURL message is just a string. The hub doesn't have enough information to work out that it's the name of a temporary file which needs to be deleted once it's no longer in use. It's only likely to be the sending application which knows whether that's the case or not. To prevent this kind of confusion though, maybe there should be something explicit in the message definition for loadURL which says that the URL is only guaranteed to remain usable between when the message is sent and when the receiver provides the return value (or possibly some other policy we agree on). Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: John T. <jon...@gm...> - 2006-07-04 11:46:02
|
Mark Taylor wrote: > On Tue, 4 Jul 2006, B Walshe wrote: > > >> Quoting Mark Taylor <m.b...@br...>: >> >> >> >>> my best guess for what's happening here is that TOPCAT is writing the >>> temporary file (in /tmp/plastic*.vot, as John says), but then deleting >>> it before Eirik has read it. What it does for a table broadcast/transmit is: >>> >>> 1. Write a VOTable representing the current state of the table to >>> be sent to a temporary file >>> 2. Send the loadFromURL message >>> 3. Wait for the response object from the hub describing which >>> listeners succeeded and which failed to load the table >>> 4. Delete the temporary file >>> >>> So you might well see what you are seeing if you are replying to the >>> loadFromUrl (returning a true/false error status) before you've actually >>> consumed the temporary file. >>> >>> Is that what you're doing? >>> >>> Mark >>> >>> >> Yes, I think I might be sending the response before I load the table. I >> have my message handler and table loader running in separate threads. >> > > that would make sense then - hope it's not too difficult for you to > work round it. There's nothing in the message definition that says > how persistent that URL should be, Maybe there should be some clarification. It seems to me that keeping the table there until all the apps respond with "OK" is a reasonable thing to do for temporary files generated by the sender. I'm not sure what to do if the sending application didn't generate the file or if it sends the message asynchronously. If the sender didn't create the file it has no control over how long it will persist (for example, the file may have been created by a SIA service), and if the sender sends the message asynch it has no way of knowing when the file has been picked up by the receivers. Is it good enough for us to say that the files should be considered temporary and loaded (or copied) "in good time", certainly before the receiver responds with "OK"? > but I like to clear it up quite > soon to prevent overuse of temporary disk space. If it's causing > problems which are difficult to solve for you or Richard as message > receivers I could reconsider how TOPCAT goes about this. > > Mark > > |
|
From: R H. <ric...@co...> - 2006-07-04 11:40:29
|
On Tue, 4 Jul 2006, Mark Taylor wrote: > On Tue, 4 Jul 2006, B Walshe wrote: > >> Quoting Mark Taylor <m.b...@br...>: >> >> >>> my best guess for what's happening here is that TOPCAT is writing the >>> temporary file (in /tmp/plastic*.vot, as John says), but then deleting >>> it before Eirik has read it. What it does for a table broadcast/transmit is: >>> >>> 1. Write a VOTable representing the current state of the table to >>> be sent to a temporary file >>> 2. Send the loadFromURL message >>> 3. Wait for the response object from the hub describing which >>> listeners succeeded and which failed to load the table >>> 4. Delete the temporary file >>> >>> So you might well see what you are seeing if you are replying to the >>> loadFromUrl (returning a true/false error status) before you've actually >>> consumed the temporary file. >>> >>> Is that what you're doing? >>> >>> Mark >>> >> >> Yes, I think I might be sending the response before I load the table. I >> have my message handler and table loader running in separate threads. > > that would make sense then - hope it's not too difficult for you to > work round it. There's nothing in the message definition that says > how persistent that URL should be, but I like to clear it up quite > soon to prevent overuse of temporary disk space. If it's causing > problems which are difficult to solve for you or Richard as message > receivers I could reconsider how TOPCAT goes about this. > > Mark > apologies, since I wandered off to something else for a while... haven't tested it but I'm sure this is the same (threading issue) for me. It occurs to me though that unless all apps check all returning messages to a general broadcast, this could be messy. Perhaps file cleaning might be better placed in the hub... ? Richard |
|
From: Mark T. <m.b...@br...> - 2006-07-04 11:10:55
|
On Tue, 4 Jul 2006, B Walshe wrote: > Quoting Mark Taylor <m.b...@br...>: > > > > my best guess for what's happening here is that TOPCAT is writing the > > temporary file (in /tmp/plastic*.vot, as John says), but then deleting > > it before Eirik has read it. What it does for a table broadcast/transmit is: > > > > 1. Write a VOTable representing the current state of the table to > > be sent to a temporary file > > 2. Send the loadFromURL message > > 3. Wait for the response object from the hub describing which > > listeners succeeded and which failed to load the table > > 4. Delete the temporary file > > > > So you might well see what you are seeing if you are replying to the > > loadFromUrl (returning a true/false error status) before you've actually > > consumed the temporary file. > > > > Is that what you're doing? > > > > Mark > > > > Yes, I think I might be sending the response before I load the table. I > have my message handler and table loader running in separate threads. that would make sense then - hope it's not too difficult for you to work round it. There's nothing in the message definition that says how persistent that URL should be, but I like to clear it up quite soon to prevent overuse of temporary disk space. If it's causing problems which are difficult to solve for you or Richard as message receivers I could reconsider how TOPCAT goes about this. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: B W. <s05...@sm...> - 2006-07-04 10:48:46
|
Quoting Mark Taylor <m.b...@br...>: > my best guess for what's happening here is that TOPCAT is writing the > temporary file (in /tmp/plastic*.vot, as John says), but then deleting > it before Eirik has read it. What it does for a table broadcast/transmit is: > > 1. Write a VOTable representing the current state of the table to > be sent to a temporary file > 2. Send the loadFromURL message > 3. Wait for the response object from the hub describing which > listeners succeeded and which failed to load the table > 4. Delete the temporary file > > So you might well see what you are seeing if you are replying to the > loadFromUrl (returning a true/false error status) before you've actually > consumed the temporary file. > > Is that what you're doing? > > Mark > Yes, I think I might be sending the response before I load the table. I have my message handler and table loader running in separate threads. Sound, Brian. |
|
From: Mark T. <m.b...@br...> - 2006-07-03 13:38:23
|
On Mon, 3 Jul 2006, John Taylor wrote:
> R Holbrey wrote:
> >
> > hi guys,
> >
> > if I tell eirik to load a votable via the interop menu (using
> > broadcast or send table) of topcat I get a request to "loadFromURL" a
> > file such as:
> >
> > file://localhost/tmp/plastic63074.vot
> >
> > despite working around 'numer-of-slashes' saga, I can't really find
> > any reference to such a file on my system, that is I would expect to
> > find something in either
> >
> > /tmp/plastic63074.vot or ./tmp/plastic63074.vot
> It should be the former. Funny that you can't find it. Brian Walshe
> had a similar problem this week receiving a file from Topcat. I didn't
> think anything of it...just assumed he was not doing file handling
> properly. I'll check that I'm seeing the file OK on my system....
Richard and John (and Brian),
my best guess for what's happening here is that TOPCAT is writing the
temporary file (in /tmp/plastic*.vot, as John says), but then deleting
it before Eirik has read it. What it does for a table broadcast/transmit is:
1. Write a VOTable representing the current state of the table to
be sent to a temporary file
2. Send the loadFromURL message
3. Wait for the response object from the hub describing which
listeners succeeded and which failed to load the table
4. Delete the temporary file
So you might well see what you are seeing if you are replying to the
loadFromUrl (returning a true/false error status) before you've actually
consumed the temporary file.
Is that what you're doing?
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|
|
From: Mark T. <m.b...@br...> - 2006-05-11 12:37:30
|
Hey Plastic, I've made new public releases of TOPCAT and STILTS. Mostly these contain bugfixes and enhancements that I've provided in pre-release versions over the last few weeks. Of interest to this list: - TOPCAT can now send and receive ivo://votech.org/votable/highlightObject - STILTS now has a "plastic" output mode which can broadcast tables to one or all registered listeners using (configurably) either ivo://votech.org/votable/load or ivo://votech.org/votable/loadFromURL TOPCAT v2.1-3: http://www.starlink.ac.uk/topcat/ STILTS v1.1: http://www.starlink.ac.uk/stilts/ Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Marco C. <mc...@oa...> - 2006-05-11 10:44:23
|
Mark Taylor wrote: > all a bit of a mystery to me, though it may have something to do with > what John said about the difference between starting from DOS prompt or > Windows. I'll try to investigate. Hi, I have news. Everything works fine if I start VisIVO out of visual studio, so the problem is not in TOPCAT, it is not in VisIVO, it is not in Windows, it is in my ******* old visual studio. Cheers, Marco -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: John T. <jon...@gm...> - 2006-05-11 05:55:22
|
Another possibility is that we disallow file:// URLs completely and
create a new loadFromFile message.
I don't really like this idea myself though.
John
Thomas Boch wrote:
> Mark,
>
> That's very annoying indeed.
> I think that PLASTIC-aware Java applications should still be able to
> deal with file URLs of the form "file://localhost/path" as those URLs
> are perfectly valid. Thus, the workaround #1 seems indispensable IMHO.
>
> Thomas
>
>
> Mark Taylor wrote:
>
>> On Wed, 10 May 2006, Johan Lindroos wrote:
>>
>>
>>> Hello Mark,
>>>
>>> I did some more tests, and get weird symptoms :-/
>>>
>>> The working version i have is when I create an URL url object from the
>>> incoming string.
>>> from that i create a File object new File(url.getPath()); this works nicely
>>>
>>> But also the following should work.
>>>
>>> URL url = new URL(incoming)
>>> URI uri = url.toURI();
>>>
>>> File file = new File(uri);
>>> //program locks here without any exceptions if the url contained the
>>> localhost part, if you remove the localhost before creating the url obj
>>> it works nicely also.
>>>
>> Yes, I get the following error there:
>>
>> java.lang.IllegalArgumentException: URI has an authority component
>>
>> If I feed the File(URI) constructor a URI which does not contain the
>> authority component (e.g. "file:///path" rather than
>> "file://localhost/path") this problem goes away. However Java won't
>> let you create URLs in this form: the result of
>> new URL("file:///path").toExternalForm() is "file:/path".
>>
>>
>>> It seems as it's actually java that does not follow the URL standards I
>>> think.
>>>
>> Unfortunately that's true - see
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351751
>>
>> What a mess. It seems impossible to pass around URL/URI objects
>> in any form which both conforms to RFC1738 and which Java won't
>> choke on under some circumstances.
>>
>> The only workarounds I can think of for this are as follows:
>>
>> 1. Avoid use of the File(URI) constructor. There may be other places
>> where similar problems crop up - we'll have to watch for these.
>>
>> 2. Give in and use non-conformant file-scheme URLs in the form
>> that Java produces them (file:path); this will effectively
>> require non-java PLASTIC applications to be prepared to
>> deal with illegal URLs.
>>
>> 3. Wait until Sun fixes it. I suspect that might take a while
>> because of backward compatiblity problems, and in any case
>> this doesn't help applications running on older JVMs.
>>
>> 1 is probably the Right Thing To Do. However, since new java
>> applications are going to keep tripping over this and in practice
>> it's a lot more fiddly to fix than you might think, I suspect the
>> best thing to do in practice is 2. This requires the java
>> PLASTICers humbly to ask the non-java PLASTICers to accommodate
>> the deficiencies of the J2SE. Does anyone from either the java or
>> non-java side have an opinion on this?
>>
>> Mark
>>
>>
>>>> On Wed, 10 May 2006, Johan Lindroos wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hello Mark,
>>>>>
>>>>> I got the same problem in windows, but the problem is not due to the
>>>>> "8char" directories but the localhost part, that does not work well,
>>>>> when removing the localhost from the url before accessing the temporary
>>>>> file it works well.
>>>>>
>>>>> Best Regards,
>>>>> Johan
>>>>>
>>>>> Johan Lindroos, Software Engineer, SAMPO ESO - Data Analysis Project
>>>>> P.O.Box 405, 02101 ESPOO, Finland Tel.+358-9-4572121, Mob.+358-50-3819725, Fax. +358-9-4572302
>>>>> CSC - Scientific Computing Ltd. http://www.csc.fi Email: Joh...@cs...
>>>>>
>>>>>
>>>>>
>>>> oh lordy... the URLs generated by TOPCAT didn't used to contain the
>>>> localhost part in 'file:'-type URLs, but I've done work to insert it
>>>> following discussions on this list last month about correctly
>>>> formed URLs, in accordance with RFC 1738. Now it seems that they
>>>> are not being parsed correctly.
>>>>
>>>> Can you tell me exactly what is failing when trying to handle such URLs?
>>>>
>>>> thanks
>>>>
>>>> Mark
>>>>
>> --
>> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
>> m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Plastic-devs mailing list
>> Pla...@li...
>> https://lists.sourceforge.net/lists/listinfo/plastic-devs
>>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Plastic-devs mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/plastic-devs
>
>
|
|
From: John T. <jon...@gm...> - 2006-05-11 05:54:09
|
Mark Taylor wrote: > On Wed, 10 May 2006, Thomas Boch wrote: > > >> Mark, >> >> That's very annoying indeed. >> I think that PLASTIC-aware Java applications should still be able to >> deal with file URLs of the form "file://localhost/path" as those URLs >> are perfectly valid. Thus, the workaround #1 seems indispensable IMHO. >> > > Yes, that's true. I suppose that we stick with our decision that > PLASTIC messages ought always to contain legal URLs, and all > applications must be able to deal with them; however we might > informally advise authors of non-java PLASTIC applications that they > may have more luck communicating with (poorly-written) java ones > if they are a bit flexible about the URLs they can accept. > > I think that was the advice I gave to Marco a while back! This discussion does make me think that we need some kind of Plastic-tester application. It's already very easy for a Java programmer to send a plastic message with arguments that aren't valid xml-rpc. This sort of error wouldn't show up when sent between two java apps (at least in the AR implementation of the hub). I'm sure there are plenty of other gotchas that we could try to trap. John > Mark > > |
|
From: John T. <jon...@gm...> - 2006-05-11 05:50:27
|
I agree that it's likely that other Java programmers will trip up on
this, but we could put a prominent note on the core messages page
warning people (there's already something written there....I'll just add
a <blink></blink> around it ;-) ).
If they use a plastic client library like yours or mine this feature
could be built in so application developers wouldn't be aware of it.
I feel it's wrong to ask the C++ers and Perlists to work around Java's
deficiencies.
John
Mark Taylor wrote:
> On Wed, 10 May 2006, Johan Lindroos wrote:
>
>
>> Hello Mark,
>>
>> I did some more tests, and get weird symptoms :-/
>>
>> The working version i have is when I create an URL url object from the
>> incoming string.
>> from that i create a File object new File(url.getPath()); this works nicely
>>
>> But also the following should work.
>>
>> URL url = new URL(incoming)
>> URI uri = url.toURI();
>>
>> File file = new File(uri);
>> //program locks here without any exceptions if the url contained the
>> localhost part, if you remove the localhost before creating the url obj
>> it works nicely also.
>>
>
> Yes, I get the following error there:
>
> java.lang.IllegalArgumentException: URI has an authority component
>
> If I feed the File(URI) constructor a URI which does not contain the
> authority component (e.g. "file:///path" rather than
> "file://localhost/path") this problem goes away. However Java won't
> let you create URLs in this form: the result of
> new URL("file:///path").toExternalForm() is "file:/path".
>
>
>> It seems as it's actually java that does not follow the URL standards I
>> think.
>>
>
> Unfortunately that's true - see
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351751
>
> What a mess. It seems impossible to pass around URL/URI objects
> in any form which both conforms to RFC1738 and which Java won't
> choke on under some circumstances.
>
> The only workarounds I can think of for this are as follows:
>
> 1. Avoid use of the File(URI) constructor. There may be other places
> where similar problems crop up - we'll have to watch for these.
>
> 2. Give in and use non-conformant file-scheme URLs in the form
> that Java produces them (file:path); this will effectively
> require non-java PLASTIC applications to be prepared to
> deal with illegal URLs.
>
> 3. Wait until Sun fixes it. I suspect that might take a while
> because of backward compatiblity problems, and in any case
> this doesn't help applications running on older JVMs.
>
> 1 is probably the Right Thing To Do. However, since new java
> applications are going to keep tripping over this and in practice
> it's a lot more fiddly to fix than you might think, I suspect the
> best thing to do in practice is 2. This requires the java
> PLASTICers humbly to ask the non-java PLASTICers to accommodate
> the deficiencies of the J2SE. Does anyone from either the java or
> non-java side have an opinion on this?
>
> Mark
>
>
>>> On Wed, 10 May 2006, Johan Lindroos wrote:
>>>
>>>
>>>
>>>
>>>> Hello Mark,
>>>>
>>>> I got the same problem in windows, but the problem is not due to the
>>>> "8char" directories but the localhost part, that does not work well,
>>>> when removing the localhost from the url before accessing the temporary
>>>> file it works well.
>>>>
>>>> Best Regards,
>>>> Johan
>>>>
>>>> Johan Lindroos, Software Engineer, SAMPO ESO - Data Analysis Project
>>>> P.O.Box 405, 02101 ESPOO, Finland Tel.+358-9-4572121, Mob.+358-50-3819725, Fax. +358-9-4572302
>>>> CSC - Scientific Computing Ltd. http://www.csc.fi Email: Joh...@cs...
>>>>
>>>>
>>>>
>>> oh lordy... the URLs generated by TOPCAT didn't used to contain the
>>> localhost part in 'file:'-type URLs, but I've done work to insert it
>>> following discussions on this list last month about correctly
>>> formed URLs, in accordance with RFC 1738. Now it seems that they
>>> are not being parsed correctly.
>>>
>>> Can you tell me exactly what is failing when trying to handle such URLs?
>>>
>>> thanks
>>>
>>> Mark
>>>
>
>
|
|
From: John T. <jon...@gm...> - 2006-05-11 05:36:09
|
FWIW I believe that the localhost bit is optional, and you could do file://localhost/path/file or file:///path/file John Mark Taylor wrote: > On Wed, 10 May 2006, Johan Lindroos wrote: > > >> Hello Mark, >> >> I got the same problem in windows, but the problem is not due to the >> "8char" directories but the localhost part, that does not work well, >> when removing the localhost from the url before accessing the temporary >> file it works well. >> >> Best Regards, >> Johan >> >> Johan Lindroos, Software Engineer, SAMPO ESO - Data Analysis Project >> P.O.Box 405, 02101 ESPOO, Finland Tel.+358-9-4572121, Mob.+358-50-3819725, Fax. +358-9-4572302 >> CSC - Scientific Computing Ltd. http://www.csc.fi Email: Joh...@cs... >> > > oh lordy... the URLs generated by TOPCAT didn't used to contain the > localhost part in 'file:'-type URLs, but I've done work to insert it > following discussions on this list last month about correctly > formed URLs, in accordance with RFC 1738. Now it seems that they > are not being parsed correctly. > > Can you tell me exactly what is failing when trying to handle such URLs? > > thanks > > Mark > > |
|
From: John T. <jon...@gm...> - 2006-05-11 05:24:12
|
Coming in rather late...I agree...let's change the documentation to fit the reality. I don't think anyone but you two guys currently support the message anyhow. J Mark Taylor wrote: > On Tue, 9 May 2006, Thomas Boch wrote: > > >>> With hindsight I'd say that the way the change was made was suboptimal - >>> if the parameter list change had been >>> >>> (String votable) -> (String votable, String id) >>> >>> rather than >>> >>> (String votable) -> (String id, String votable) >>> >> Note that the current version of Aladin incorrectly expects that the >> parameter list is (String votable, String id) ... >> > > I didn't realise that - in that case since we (well, I) agree it's > better that way, and that's what Aladin does, it might be best > to declare that the bug is in the specification and just change that. > Is there code anywhere which uses this method in the declared > (String id, String votable) form? > > Mark > > |
|
From: Mark T. <m.b...@br...> - 2006-05-10 11:58:24
|
On Wed, 10 May 2006, Thomas Boch wrote: > Mark, > > That's very annoying indeed. > I think that PLASTIC-aware Java applications should still be able to > deal with file URLs of the form "file://localhost/path" as those URLs > are perfectly valid. Thus, the workaround #1 seems indispensable IMHO. Yes, that's true. I suppose that we stick with our decision that PLASTIC messages ought always to contain legal URLs, and all applications must be able to deal with them; however we might informally advise authors of non-java PLASTIC applications that they may have more luck communicating with (poorly-written) java ones if they are a bit flexible about the URLs they can accept. Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ |
|
From: Thomas B. <bo...@ne...> - 2006-05-10 11:47:15
|
Mark,
That's very annoying indeed.
I think that PLASTIC-aware Java applications should still be able to
deal with file URLs of the form "file://localhost/path" as those URLs
are perfectly valid. Thus, the workaround #1 seems indispensable IMHO.
Thomas
Mark Taylor wrote:
>
> On Wed, 10 May 2006, Johan Lindroos wrote:
>
> > Hello Mark,
> >
> > I did some more tests, and get weird symptoms :-/
> >
> > The working version i have is when I create an URL url object from the
> > incoming string.
> > from that i create a File object new File(url.getPath()); this works nicely
> >
> > But also the following should work.
> >
> > URL url = new URL(incoming)
> > URI uri = url.toURI();
> >
> > File file = new File(uri);
> > //program locks here without any exceptions if the url contained the
> > localhost part, if you remove the localhost before creating the url obj
> > it works nicely also.
>
> Yes, I get the following error there:
>
> java.lang.IllegalArgumentException: URI has an authority component
>
> If I feed the File(URI) constructor a URI which does not contain the
> authority component (e.g. "file:///path" rather than
> "file://localhost/path") this problem goes away. However Java won't
> let you create URLs in this form: the result of
> new URL("file:///path").toExternalForm() is "file:/path".
>
> > It seems as it's actually java that does not follow the URL standards I
> > think.
>
> Unfortunately that's true - see
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351751
>
> What a mess. It seems impossible to pass around URL/URI objects
> in any form which both conforms to RFC1738 and which Java won't
> choke on under some circumstances.
>
> The only workarounds I can think of for this are as follows:
>
> 1. Avoid use of the File(URI) constructor. There may be other places
> where similar problems crop up - we'll have to watch for these.
>
> 2. Give in and use non-conformant file-scheme URLs in the form
> that Java produces them (file:path); this will effectively
> require non-java PLASTIC applications to be prepared to
> deal with illegal URLs.
>
> 3. Wait until Sun fixes it. I suspect that might take a while
> because of backward compatiblity problems, and in any case
> this doesn't help applications running on older JVMs.
>
> 1 is probably the Right Thing To Do. However, since new java
> applications are going to keep tripping over this and in practice
> it's a lot more fiddly to fix than you might think, I suspect the
> best thing to do in practice is 2. This requires the java
> PLASTICers humbly to ask the non-java PLASTICers to accommodate
> the deficiencies of the J2SE. Does anyone from either the java or
> non-java side have an opinion on this?
>
> Mark
>
> >
> > >On Wed, 10 May 2006, Johan Lindroos wrote:
> > >
> > >
> > >
> > >>Hello Mark,
> > >>
> > >>I got the same problem in windows, but the problem is not due to the
> > >>"8char" directories but the localhost part, that does not work well,
> > >>when removing the localhost from the url before accessing the temporary
> > >>file it works well.
> > >>
> > >>Best Regards,
> > >> Johan
> > >>
> > >>Johan Lindroos, Software Engineer, SAMPO ESO - Data Analysis Project
> > >>P.O.Box 405, 02101 ESPOO, Finland Tel.+358-9-4572121, Mob.+358-50-3819725, Fax. +358-9-4572302
> > >>CSC - Scientific Computing Ltd. http://www.csc.fi Email: Joh...@cs...
> > >>
> > >>
> > >
> > >oh lordy... the URLs generated by TOPCAT didn't used to contain the
> > >localhost part in 'file:'-type URLs, but I've done work to insert it
> > >following discussions on this list last month about correctly
> > >formed URLs, in accordance with RFC 1738. Now it seems that they
> > >are not being parsed correctly.
> > >
> > >Can you tell me exactly what is failing when trying to handle such URLs?
> > >
> > >thanks
> > >
> > >Mark
>
> --
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Plastic-devs mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/plastic-devs
|
|
From: Mark T. <m.b...@br...> - 2006-05-10 11:20:52
|
On Wed, 10 May 2006, Johan Lindroos wrote:
> Hello Mark,
>
> I did some more tests, and get weird symptoms :-/
>
> The working version i have is when I create an URL url object from the
> incoming string.
> from that i create a File object new File(url.getPath()); this works nicely
>
> But also the following should work.
>
> URL url = new URL(incoming)
> URI uri = url.toURI();
>
> File file = new File(uri);
> //program locks here without any exceptions if the url contained the
> localhost part, if you remove the localhost before creating the url obj
> it works nicely also.
Yes, I get the following error there:
java.lang.IllegalArgumentException: URI has an authority component
If I feed the File(URI) constructor a URI which does not contain the
authority component (e.g. "file:///path" rather than
"file://localhost/path") this problem goes away. However Java won't
let you create URLs in this form: the result of
new URL("file:///path").toExternalForm() is "file:/path".
> It seems as it's actually java that does not follow the URL standards I
> think.
Unfortunately that's true - see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6351751
What a mess. It seems impossible to pass around URL/URI objects
in any form which both conforms to RFC1738 and which Java won't
choke on under some circumstances.
The only workarounds I can think of for this are as follows:
1. Avoid use of the File(URI) constructor. There may be other places
where similar problems crop up - we'll have to watch for these.
2. Give in and use non-conformant file-scheme URLs in the form
that Java produces them (file:path); this will effectively
require non-java PLASTIC applications to be prepared to
deal with illegal URLs.
3. Wait until Sun fixes it. I suspect that might take a while
because of backward compatiblity problems, and in any case
this doesn't help applications running on older JVMs.
1 is probably the Right Thing To Do. However, since new java
applications are going to keep tripping over this and in practice
it's a lot more fiddly to fix than you might think, I suspect the
best thing to do in practice is 2. This requires the java
PLASTICers humbly to ask the non-java PLASTICers to accommodate
the deficiencies of the J2SE. Does anyone from either the java or
non-java side have an opinion on this?
Mark
>
> >On Wed, 10 May 2006, Johan Lindroos wrote:
> >
> >
> >
> >>Hello Mark,
> >>
> >>I got the same problem in windows, but the problem is not due to the
> >>"8char" directories but the localhost part, that does not work well,
> >>when removing the localhost from the url before accessing the temporary
> >>file it works well.
> >>
> >>Best Regards,
> >> Johan
> >>
> >>Johan Lindroos, Software Engineer, SAMPO ESO - Data Analysis Project
> >>P.O.Box 405, 02101 ESPOO, Finland Tel.+358-9-4572121, Mob.+358-50-3819725, Fax. +358-9-4572302
> >>CSC - Scientific Computing Ltd. http://www.csc.fi Email: Joh...@cs...
> >>
> >>
> >
> >oh lordy... the URLs generated by TOPCAT didn't used to contain the
> >localhost part in 'file:'-type URLs, but I've done work to insert it
> >following discussions on this list last month about correctly
> >formed URLs, in accordance with RFC 1738. Now it seems that they
> >are not being parsed correctly.
> >
> >Can you tell me exactly what is failing when trying to handle such URLs?
> >
> >thanks
> >
> >Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|
29 messages has been excluded from this view by a project administrator.
