Re: [Plastic-devs] file-scheme URLs again

[John T. <jon...@gm...>]

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
>
>