river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Jones <peter.jo...@sun.com>
Subject Re: Change for PreferredClassLoader its way of determining the existence of PREFERRED.LIST ?
Date Tue, 16 Jan 2007 21:26:05 GMT
On Thu, Jan 11, 2007 at 11:02:42PM +0100, Mark Brouwer wrote:
> 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.

What is not obvious from your above prescription is, in the event that
the attempt to retrieve the first URL throws an IOException, whether
PreferredClassLoader.isPreferredResource should return false or throw
an IOException.  If the failure indicates that that referenced JAR
file itself definitely does not exist (like because the HTTP server
responded with 404), then isPreferredResource should return false, so
that class loader delegation can proceed.  But if the failure is less
definite about the JAR file's existence, then isPreferredResource
should throw an IOException, because perhaps it was the deployer's
intention that the class or resource be preferred and thus it would be
wrong for class loader delegation to succeed just because of a
transient communication failure.

I don't recall the details offhand (is Laird subscribed to this
list?), but I believe that the general problem was that information
necessary to make this decision was not exposed when using a "jar:"
URL, at least for the JDK implementations of the time (early 1.4).
The PreferredClassLoader logic in question was added as part of the
fix for the following bug (this was back when PreferredClassLoader was
still transitioning out of JDK 1.4 itself):


(although the text of that bug report doesn't necessarily illuminate
the particular issues behind that logic).

-- Peter

View raw message