Bug 32527 - log4j initialization in java1.3 no dom in class path.
log4j initialization in java1.3 no dom in class path.
Status: RESOLVED FIXED
Product: Log4j
Classification: Unclassified
Component: Configurator
1.2
PC Windows XP
: P2 normal
: ---
Assigned To: log4j-dev
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2004-12-04 01:57 UTC by Vlad Skarzhevskyy
Modified: 2007-08-22 15:39 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vlad Skarzhevskyy 2004-12-04 01:57:46 UTC
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);
Comment 1 Jacob Kjome 2004-12-04 07:07:06 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
Comment 2 Vlad Skarzhevskyy 2004-12-06 03:53:20 UTC
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
Comment 3 Curt Arnold 2007-08-22 15:39:59 UTC
Added try/catch block in LogManager's default initialization code in rev 568761.