Summary: | log4j initialization in java1.3 no dom in class path. | ||
---|---|---|---|
Product: | Log4j - Now in Jira | Reporter: | Vlad Skarzhevskyy <skarzhevskyy> |
Component: | Configurator | Assignee: | log4j-dev <log4j-dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 1.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Vlad Skarzhevskyy
2004-12-04 01:57:46 UTC
I can sort of see your point here that Log4j should do something more useful than allow a NoClassDefFoundError or the like to propogate to the user and kill the app. Or, at a minimum, provide a clear stacktrace showing the reason for the error as you have below. However, I would also argue that you have made a conscious choice to use an XML config file and ought to also be expected to make sure that the standard XML libraries are in the classpath as well. What else is going to parse an XML file? You can avoid all this by simply using a Properties file. In any case, this is not likely to be addressed in Log4j-1.2.x since Log4j-1.3 is now the actively developed version. I don't see this as super high priority, but it's not a bad idea. If you provide a patch, this will get addressed much more quickly. And keep in mind that the JoranConfigurator is now the default XML config file parser for Log4j, not DOMConfigurator which is deprecated. Just check out the HEAD branch of the logging-log4j module and create a patch against that. Jake The case was simple I forgot to add dom implementation to calss path because I was testing in 1.4 initialy. Then I started to test in 1.3 and had been very disappointed because My app was realy complex and calsses was instrumented using javassist under java 1.4 and then run under 1.3. So I was thinking that somthing wron happens during instumentation and so on. Spend hell of the time debudin instrumentation and removing all 1.4 classes from my app that was not realy used in the application but did not know that untill I fixed it all. And finaly I decided to catch exception in one class and then call my main class. Any way I submited the bug because this is: "not a bad idea" -- Vlad Added try/catch block in LogManager's default initialization code in rev 568761. |