Hello Marcus! MC> However, if you move the call to getInputStream() to be after MC> getResponseCode() then no exception is MC> raised and and you'll receive a valid InputStream containing the error MC> page from the server.
Who will report it to Sun, you or me? :-) MC> I've attached a patch that examines the return code ... MC> This fixes the problem, but prevents people from parsing error pages Have not used it, but from the top of my head, why would one want to parse that? The only thing that I dislike in this patch (other then that I do like it very much :-) is that we're going to get a _very_ long error message in our log probably. To me it makes perfect sense to struggle for the logs to be compact and readable (not outputting stack traces when not necessary like Merlin does, etc.). In this context outputting the whole error page from the server does not seem good to me. Do you think URLSource could hold either of * a link to its parent URLSourceFactory and use its logger * a link to URLSourceFactory's logger and log that page with DEBUG priority instead? My opinion would be that in most cases the error code will be enough in the exception message. Alternatively we could subclass this exception and hook the error page to the exception some other way, not as part of the message and the user decide what to do about the exception. Thoughts? -Anton --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
