On May 18, 2006, at 2:19 PM, Christian Haase wrote:
Have done a run with -Dlog4j.debug, but doesn't helps me:
log4j: Trying to find [/work/fop/entwicklung/log4j.properties]
using context classloader [EMAIL PROTECTED]
log4j: Trying to find [/work/fop/entwicklung/log4j.properties]
using [EMAIL PROTECTED] class loader.
log4j: Trying to find [/work/fop/entwicklung/log4j.properties]
using ClassLoader.getSystemResource().
log4j: Could not find resource: [/work/fop/entwicklung/
log4j.properties].
The path to log4j.poperties file is absolutely correct and the user
the java application runs with has authorization for reading the file.
I've no idea what's going wrong here. If you have any ideas, please
let me know!
Greetings,
Christian
log4j.configuration=/work/fop/entwicklung/log4j.properties <---
Looks
right, or not?
java.library.path=/usr/lib/SunJava2-1.4.2/jre/lib/i386/...
The code that handles this in in org.apache.log4j.LogManager's static
initializer. The value log4j.configuration is expected to be either
a URL or an resource identifier in the class path. The debug log
confirms that it is was not recognized as a URL and it could not be
found on the classpath (where it would be looking inside the jars in
the same way it would try to find org.apache.log4j.Logger.class).
Since the java.net.URL class likely delegates to the OS on Windows,
then invalid URL's (particular ones with backslashes) might be
accepted that fail on other platforms.
Your options would be to set log4j.configuration to a file: URL (for
example, file:///work/fop/entwicklung/log4j.properties), add the root
directory to the classpath or add the log4j.properties files to one
of the jars or directories already in the classpath.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
