> From: jkv [mailto:[email protected]]
> Subject: RE: FileNotFoundException in Tomcat6.0
>
> But the problem starts only if you try to configure using a
> PropertyConfigurator having the same file there and use the
> above statement then you get FNFExe because the classpath is
> acutally bin folder of Tomcat and log4j searches the bin
> folder for a log4j.configuration which is actually strange.
I'm not sure I believe that - log4j should be using the webapp's classloader,
not the system classloader. Sounds like a bug in log4j or how you have it
installed.
> So you will have to use this statement
> PropertyConfigurator.configure(servletContext.getRealPath("/") +
> "/WEB-INF/classes/" + "log4j.properties");
The getRealPath() method should never be relied upon; the container is under no
obligation to return anything here. For example, if your webapp is packaged as
a .war file, it will return null. You need to fix the problem in your log4j
setup, not attack the symptom.
> The similar is the case for any file in Tomcat, ie is if you want to
> read from a custom file in tomcat say your own configurations for web
> application the you will have to use the Path for the file using the
> servletContest.getRealPath("/") + ... your expected file path starting
> from root.
That's definitely not true - the classloader path for any thread running inside
a webapp is WEB-INF/classes and WEB-INF/lib first, followed by the shared
library, and only then the system classpath. Something you're doing is
breaking the classloader model implemented by Tomcat:
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
