[jira] Created: (RIVER-293) consider removing extra retrieval of first JAR file

["Peter Jones (JIRA)" <ji...@apache.org>]

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, AR2
            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 unclear.

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:

[http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200805.mbox/%3c20080501055240.GA22614@east%3e]


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