You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Bob Scheifler <Bo...@Sun.COM> on 2008/05/01 23:28:45 UTC
Re: [jira] Resolved: (RIVER-9) PreferredClassLoader should try to
avoid making a direct check against the first URL
Peter Jones wrote:
> The other option that I can think of is that PreferredClassLoader was
> trying to be careful to only consider 4xx HTTP responses to indicate
> that the JAR file definitely does not exist, not 5xx HTTP responses,
> which are logically less definitive, but still cause
> FileNotFoundException. This seems like a plausibile explanation, but
> it doesn't ring a bell with me (Bob?).
The only difference I can find is that PreferredClassLoader treats
403 (FORBIDDEN) as definitely does not exist, whereas HttpURLConnection
throws an IOException for it. Doesn't seem like we would have really
gone to that much trouble for that one case, though.
- Bob
Re: [jira] Resolved: (RIVER-9) PreferredClassLoader should try to
avoid making a direct check against the first URL
Posted by Peter Jones <pe...@sun.com>.
On Mon, May 19, 2008 at 08:54:10PM +0200, Mark Brouwer wrote:
> Peter Jones wrote:
>> I finally uncovered an old (early 2001) email that was the code review
>> request for the change which added PreferredClassLoader's extra
>> retrieval of the first JAR file without using the "jar:" URL handler--
>> but the explanation it contains does not make sense to me. I'm now
>> inclined to think that we should just remove the extra retrieval,
>> simplifying this rather confusing code (and obviating the original
>> need for the RIVER-9 change).
>>
>
> Hi Peter, Bob,
>
> Sorry for the late response (was on holidays for while) and I'm having a
> lot of problems lately with regard to my cheiron.org mail adres.
>
> I would like to leave the code as it is for now. If the 'intriging' code
> is really not necessary it would be a good thing to simplify, but one
> could argue whether the spec for the JarURLConnection methods that throw
> IOException is enough to assume FileNotFoundException will be thrown in
> case a connection can be established and it can be determined the file
> doesn't exist.
>
> The implementations might seem to do the right thing, but as they don't
> specify when FileNotFoundException is thrown I think there is also no
> harm in the way the current codebase deals with it.
The HttpURLConnection.getErrorStream spec mentions the 404->FNFE
behavior in passing:
Returns the error stream if the connection failed but the server
sent useful data nonetheless. The typical example is when an HTTP
server responds with a 404, which will cause a
FileNotFoundException to be thrown in connect, but the server sent
an HTML help page with suggestions as to what to do.
One might read this "will cause" statement as a spec requirement, but
it is admittedly indirect in its placement and unclear in its coverage.
I'm OK with leaving the code as it is (with your RIVER-9 change) for
now-- it seems like the lower risk choice-- but I think that it would
be valuable to revise the code comments to clarify that the
PreferredClassLoader implementation is making this extra effort to
cover itself in the case of an imagined JarURLConnection
implementation behavior that is not believed to actually exist.
(Otherwise someone studying the code might reasonably assume that
there was a motivating case in practice and struggle to understand
what it could be, before discovering this mailing list thread.)
> One might create an issue for this, however.
Yup. I'll file one.
-- Peter
Re: [jira] Resolved: (RIVER-9) PreferredClassLoader should try to
avoid making a direct check against the first URL
Posted by Mark Brouwer <ma...@marbro.org>.
Peter Jones wrote:
> I finally uncovered an old (early 2001) email that was the code review
> request for the change which added PreferredClassLoader's extra
> retrieval of the first JAR file without using the "jar:" URL handler--
> but the explanation it contains does not make sense to me. I'm now
> inclined to think that we should just remove the extra retrieval,
> simplifying this rather confusing code (and obviating the original
> need for the RIVER-9 change).
>
Hi Peter, Bob,
Sorry for the late response (was on holidays for while) and I'm having a
lot of problems lately with regard to my cheiron.org mail adres.
I would like to leave the code as it is for now. If the 'intriging' code
is really not necessary it would be a good thing to simplify, but one
could argue whether the spec for the JarURLConnection methods that throw
IOException is enough to assume FileNotFoundException will be thrown in
case a connection can be established and it can be determined the file
doesn't exist.
The implementations might seem to do the right thing, but as they don't
specify when FileNotFoundException is thrown I think there is also no
harm in the way the current codebase deals with it.
One might create an issue for this, however.
Regards,
--
Mark Brouwer
Re: [jira] Resolved: (RIVER-9) PreferredClassLoader should try to
avoid making a direct check against the first URL
Posted by Peter Jones <pe...@sun.com>.
I finally uncovered an old (early 2001) email that was the code review
request for the change which added PreferredClassLoader's extra
retrieval of the first JAR file without using the "jar:" URL handler--
but the explanation it contains does not make sense to me. I'm now
inclined to think that we should just remove the extra retrieval,
simplifying this rather confusing code (and obviating the original
need for the RIVER-9 change).
-- Peter
Re: [jira] Resolved: (RIVER-9) PreferredClassLoader should try to
avoid making a direct check against the first URL
Posted by Peter Jones <pe...@sun.com>.
On Thu, May 01, 2008 at 05:28:45PM -0400, Bob Scheifler wrote:
> Peter Jones wrote:
>> The other option that I can think of is that PreferredClassLoader was
>> trying to be careful to only consider 4xx HTTP responses to indicate
>> that the JAR file definitely does not exist, not 5xx HTTP responses,
>> which are logically less definitive, but still cause
>> FileNotFoundException.
Oops, I had gotten confused by looking at too many (old) JDK versions
yesterday-- the above (FNFE thrown for any response code 400 or above)
was true through 1.3.1, but since 1.4 and the fix for 4160499, a FNFE
is thrown only if the response code is 404 or 410, otherwise a generic
IOException is thrown, consistent with what Bob says below.
>> This seems like a plausibile explanation, but it doesn't ring a
>> bell with me (Bob?).
>
> The only difference I can find is that PreferredClassLoader treats
> 403 (FORBIDDEN) as definitely does not exist, whereas HttpURLConnection
> throws an IOException for it. Doesn't seem like we would have really
> gone to that much trouble for that one case, though.
Agreed.
-- Peter