river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Jones (JIRA)" <j...@apache.org>
Subject [jira] Created: (RIVER-293) consider removing extra retrieval of first JAR file
Date Tue, 20 May 2008 22:46:57 GMT
consider removing extra retrieval of first JAR file

                 Key: RIVER-293
                 URL: https://issues.apache.org/jira/browse/RIVER-293
             Project: River
          Issue Type: Improvement
          Components: net_jini_loader
    Affects Versions: AR1, jtsk_2.1, jtsk_2.0.2, jtsk_2.0.1, jtsk_2.0_002, jtsk_2.0_001, jtsk_2.0,
            Reporter: Peter Jones
            Priority: Minor

Since very early in its history (February 2001, before any Overture/Davis/2.0 releases), {{PreferredClassLoader}}
has included in its procedure for retrieving the preferred list from the first URL of a codebase
URL path, if it is a URL to a JAR file, an attempt to retrieve the JAR file via that URL directly,
in addition to using a "jar:" URL to obtain the contents of "/META-INF/PREFERRED.LIST" within
that JAR file.  Before the recent fix for RIVER-9, this direct JAR file retrieval was done
unconditionally before attempting to obtain the preferred list using the "jar:" URL; but since
the RIVER-9 fix, it only occurs if an attempt to connect using a "jar:" URL and get the JAR
manifest fails.  Circumventing the "jar:" URL handler is problematic because it avoids participation
in the JAR file caching mechanism of that handler, which is especially problematic if that
handler has been customized (hence RIVER-9).

The apparent purpose of this direct JAR file retrieval attempt was to work around the possibility
that the "jar:" URL handler might mask an {{IOException}} thrown by the underlying URL retrieval
attempt which would indicate definite lack of existence of the JAR file and instead throw
an {{IOException}} from which definite lack of existence cannot be concluded, which would
ultimately cause {{isPreferredResource}} to throw an {{IOException}} when it should return
{{false}}.  In particular, the surrounding code interprets {{FileNotFoundException}} thrown
from the attempt to obtain the preferred list to indicate definite lack of existence, like
of the JAR file or the preferred list within the JAR file, but it considers any other {{IOException}}
to be inconclusive.  If an HTTP request results in a 404 response, the "http:" URL handler
indeed throws a {{FileNotFoundException}} (as tangentially asserted by the spec for {{HttpURLConnection.getErrorStream}}),
thus working directly for a non-JAR codebase URL.  The apparent fear in the case of a JAR
file codebase URL is that the "jar:" URL handler would throw a different {{IOException}} if
the underlying HTTP request throws a {{FileNotFoundException}}.  This fear does not seem justified
in practice, however, because since Sun's JDK 1.3, use of a "jar:" URL containing an "http:"
URL that results in a 404 response does actually throw the underlying {{FileNotFoundException}}.

I can't seem to find a case that justifies this extra, direct JAR file retrieval attempt.
 The original code review request for the change that added this retrieval mentions the "jar:"
URL handler masking an underlying {{UnknownHostException}} and throwing a {{ZipException}}
instead, but I can't reproduce that behavior with and JDK version, and moreover, that wouldn't
seem like an interesting case anyway, because {{PreferredClassLoader}} does not consider {{UnknownHostException}}
to indicate definite lack of existence of a preferred list.  So, the original motivation is

Because this extra JAR file retrieval attempt does not seem to have a purpose in practice,
and its existence causes maintenance confusion for {{PreferredClassLoader}}, and its existence
causes other difficulties like the problem of RIVER-9, we should consider simplifying {{PreferredClassLoader}}
by removing it altogether.

This topic has been discussed in this and followup posts:


This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message