Summary: | Failed to load logging.xml for JRE 1.5.0_16 and Webstart | ||
---|---|---|---|
Product: | Log4j - Now in Jira | Reporter: | Andrejs Dembovskis <andrejs.dembovskis> |
Component: | Configurator | Assignee: | log4j-dev <log4j-dev> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | nick |
Priority: | P2 | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Andrejs Dembovskis
2008-08-28 04:45:59 UTC
I think this can be solved just by modifying line 762 in DOMConfigurator, in the method public void doConfigure(final URL url, LoggerRepository repository) Instead of parser.parse(url.toString()) it seems to work OK if we use parser.parse(url.openConnection().getInputStream()). The reason is that the url obtained via URL.toString() was broken for webstart apps in a jdk security patch for 1.5.0_16 and 1.6_07, to obscure the path to jar files in the webstart cache. openConnection still works I built a patch with this fix and it seemed to work OK for our webstart apps See my blog for more details, http://www.objectdefinitions.com/odblog/2008/fix-for-log4j-bug-45704-failed-to-load-loggingxml-for-jre-150_16-and-webstart/ Nick Passing the stream instead of the URL would result in relative URL's in entity references not properly resolving. That is if you had a configuration file that looked like: <!DOCTYPE log4j:configuration [ <!ENTITY A1 SYSTEM A1.xml> ]> <log4j:configuration> &A1; </log4j:configuration> if you only passed the stream, the parser would not know where to locate A1.xml. If you passed a URL or a InputSource, then the parser would know how the resolve A1.xml. Will have to look through the code, but it would seem the answer would be to pass the URL down through the stack instead of trying to convert the URL to a string and then back. Good observation, I didn't spot that. It looks like it will make this bug a fair bit more difficult to fix. There is no convenient method on DocumentBuilder to pass a URL instance in directly. I wonder if creating a relative URL based on the URL instance you get under webstart would even work, given how broken the webstart URL instance seems. The fix I suggested does at least appear to make things work if there is a self-contained config.xml, which I am guessing is probably the majority of cases, but it would be good to find a perfect solution to this. Right now the best workaround I can think of is to take the xml config out of the jar, and make it available via http so it can be downloaded from the web app codebase. This could have advantages anyway, since that way to change the logging config you don't have to rebuild the jars, just change the log.xml on the server. I guess a fair few apps might do it this way already There is now a bug report relating to this issue on Sun's site http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6753651 The previous bug has been marked as a duplicate of: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6746185 From the notation it appears to be fixed in 1.5.0_17. Committed workaround in log4j 1.2 in rev 734483, extras in rev 734485. |