The behavior you see on Win2k is to be expected assuming that the JVM was started from the location "G:\jakarta-tomcat-5.0.16". If you provide a relative path for the log file, the path will be relative to wherever the JVM started. If you want the file to go somewhere specific on your system and not be relative to where the JVM was started, then provide a fully qualified path.


I'm not sure about the behavior on Linux. Are you sure that the user which started Tomcat has sufficient rights to write the log file? Note that it is up to you to make sure that the directory that you are writing log files to actually exists. Log4j won't create them for you and you would get exactly this behavior. Note also that the location from where the JVM started on Linux might be different than on Windows.

I would suggest creating an environment variable which is referenced in your log4j.properties file which you can set when start the JVM for Tomcat. This will make it so you can provide a fully qualified path to the directory to write log files and not have to change your properties file when going between Windows and Linux. Eg....
log4j.appender.LOGFILE.File=${log4j.log.home}/ftp.log


Then run Tomcat with something like this...
        run_tomcat.sh -Dlog4j.log.home=/valid/path/to/an/existing/directory


Jake


At 05:43 PM 12/19/2003 -0800, you wrote:
I had a demo this week using a WAR file that i deployed many times on
Windows with great results. This week using the same WAR file on Linux for
the first time, EVERY LOGGER Call threw an exception   $%^#&  not my best
week for demos.

some hypothesis follows and i would greatly appreciate expert guidance on
this...


Note that jar "log4j-1.2.8.jar" contains PropertyConfigurator.class and that this jar is in the following 2 WebApp directories under Tomcat/BASE... NOTE ALSO that NONE of the Tomcat Common, shared, endorsed libs contain log4j-1.2.8.jar.

#1
[EMAIL PROTECTED] /cygdrive/g/jakarta-tomcat-5.0.16
$ find -name log4j-1.2.8.jar
./webapps/axis/WEB-INF/lib/log4j-1.2.8.jar
./webapps/ftp-examples/WEB-INF/lib/log4j-1.2.8.jar

---------------------
static code for log4j configuration that i use in every class...

#2
 static
    {
        log = Logger.getLogger((this.class).getName());
        PropertyConfigurator.configure(
                this.class.getClassLoader()
                        .getResource(
                                "config/log4j.properties"
                        )
        );
    }


----- log4j.properties file (elided) -----
#3
# LOGFILE is set to be a File appender using a PatternLayout.
#log4j.appender.LOGFILE=org.apache.log4j.FileAppender
log4j.appender.LOGFILE=org.apache.log4j.RollingFileAppender
log4j.appender.LOGFILE.File=logs/ftp.log <-- linux exception on this
<-- "File does NOT EXIST"



----- Behavior of War deployed on Windows...


NOTE that the code at #2 operates in a Web app. and will load
PropertyConfigurator class from the jar located at that webapp's context (
webapps/this.context/WEB-INF/lib/log4j-1.2.8.jar ).

However, in Windows, the crazy feature is that the fileAppender from #3 gets
written NOT at the Webapp's context , but a Tomcat's BASE as in
"G:\jakarta-tomcat-5.0.16\logs". This seem's impossible to me??

------- Behavior of War deployed on Linux...

every log.debug() call throws a "file does not exist" ( logs/ftp.log )
exception. Why is this? Like on Windows example above, here the Linux path
"jakarta-tomcat-5.0.16/logs" exists but the system never writes the appender
there.

Its as if on Linux, the only place it will try to write the appender is to:
   webapps/this.context/logs/ftp.log and since there is no "logs" directory
under each
web context, the error is thrown...

Since the WAR file does not define a path under every WEBAPP that includes
"this.context/logs" , all the logger calls throw exceptions...



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to