If I have log4j.xml file in calss path and don't have any dom implementation. It would be nice to catch java.lang.NoClassDefFoundError error and not load xml file at all. now it just want initialize the program at all. And Java error mesage is not so descriptive as usual. So Untill I caught the exception myself I could not figure out why and what call is missing. This is how this looks: Exception in thread "main" java.lang.NoClassDefFoundError at uut.TastCase01.method1(TastCase01.java:61) at uut.TastCase01.main(TastCase01.java:45) I'm using: log4j-1.2.9.jar, jdk1.3.1_11, Windows XP, Also I have -Dlog4j.configuration=log4jJour.xml and log4jJour.xml is in calss path. If I have: } catch (NoClassDefFoundError e) { e.printStackTrace(); } then I could see: java.lang.NoClassDefFoundError: org/w3c/dom/Node at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:232) at org.apache.log4j.helpers.OptionConverter.instantiateByClassNameOptionConverter. java:319) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure (OptionConverter.java:449 ) at org.apache.log4j.LogManager.<clinit>(LogManager.java:113) at org.apache.log4j.Logger.getLogger(Logger.java:107) at net.sf.jour.util.PropertiesBase.<clinit>(PropertiesBase.java:47) -- Vlad ps public class PropertiesBase { /*line 47*/ protected static final Logger log = Logger.getLogger (PropertiesBase.class);
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.