Bob Scheifler wrote:
First can somebody shed me light how a typical jar: handler can mask the
distinction between definite lack of existence and less definite errors.
Peter may need to correct me, but I believe the problem is that you
can't rely on being able to use the IOException thrown to determine
the category (vs getPreferredConnection using the actual HTTP
response code to make the category distinction).
Thanks for responding Bob,
I see, what would be the problem with checking against the JAR file
itself first through a URL such as:
jar:http://host/download.jar!/
In case the URLConnection returned for this URL throws *no* IOException
you can assume (?) the JAR file is localy available [1]. A next check
could be whether there is an entry named PREFERRED.LIST by creating a
URLConnection for the URL:
jar:http://host/download.jar!/META-INF/PREFERRED.LIST
Probably I still miss something in the bigger picture that explains the
current implementation.
[1] I think the assumption that any remote JAR file will be locally
cached is fair
--
Mark
