logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Bloch <bl...@laszlosystems.com>
Subject Re: best practice question: webapp relative filenames in FileAppenders
Date Mon, 15 Nov 2004 18:54:24 GMT

This does sound like the right approach, thanks! (although system 
properties will cause me problems in containers that have security 
policies...and I'd need to call out this property as settable).

Do you know if the servlet spec guarentee that the log4j properties file 
will be loaded *after* the listener is called?


Jacob Kjome wrote:

> Quoting Eric Bloch <bloch@laszlosystems.com>:
>>Jacob Kjome wrote:
>>>At 09:15 PM 11/11/2004 -0800, you wrote:
>>> >Thanks... I have a couple other requirements which constrain a solution
>>> >the solution
>>> >
>>> >The webapp (or even mulitple copies of the webapp deployed at different
>>> >paths) has to work when dropped into a variety of containers.   Dorking
>>> >with CLASSPATH and system properties are out.  I simply need someway to
>>> >tell the FileAppenders that relative pathnames should be relative to
>>> >some directory, I think.  But I need to do that *before* they try to
>>> >read/access their files.
>>> >
>>>Well, you could still set system properties that are named based on the
>>>app being deployed such as "app1.log.home" -vs- "app2.log.home" for
>>>another app.  As long as the naming scheme is both unique and
>>>predictable, then you can set the properties at application startup with
>>>a value such as context.getRealPath("/WEB-INF/logs") and reference the
>>>property in the Log4j config file.
>>Again, thanks for the continued dialog.
>>System properties are out.  I don't start my server.  A customer does.
>>I'm in the biz of making a webapp that someone else takes and runs.
>>And I want to simplify installation/configuration so as to make it
>>full-proof.  The software, as default, needs to create logfiles inside
>>the webapp.  Making an installer set this up right is also not an option.

> I think you are missing the point.  There is nothing for the deployer to do. 
> The system property is programatically set.  The name is generated dynamically
> and is based on the context path name of the application.  Although it is
> dynamically created, it is predictable.  As such, you can reference it in your
> log4j confg file.  So, if you application is at the context path of
> "/mycontext", then you can expect the dynamically generated (and
> programatically set) system property to be "mycontext.log.home".
> I do this already in the InitContextListener than I wrote for the
> logging-log4j-sandbox project.   See info here...
> http://wiki.apache.org/logging-log4j/AppContainerLogging
> If you check the source out, check out the 0.3alpha tagged version.
> Really, this is very transparent and doesn't add any extra work for a deployer
> or server admin.
>>>Your other option is to simply specify a relative path.  The location of
>>>the log files will then be determined by the location from which the JVM
>>>was started.  If you start the server from the command line then,
>>>generally, the directory in which you ran the server start command from
>>>will be the relative location where the log files will get written.  If
>>>you start as a service, you'll probably have to set the start path,
>>>otherwise it will default to (on win2k or winXP) C:\winnt\system32
>>Yah that's doesn't work for me either.   I'm not adverse to adding
>>features to log4j though.  Any recommendations on how/where to add
>>something to file appenders to make this work as I need?
> You mean like setting some static variable providing information for a base
> directory for log files so that a relative path can be added?  You can propose
> it, but I'm not sure it will be implemented.  Seriously, the first option above
> is what you want.  It works for me across servers with no extra effort by the
> deployer.  That's why I wrote it.
> Jake
>>> >And you're right... I didn't actually describe what I do today.  I don't
>>> >actually put my log4j.properties in the classpath.  My servlet code
>>> >reads the prop file from somewhere else under WEB-INF and uses a
>>> >PropertyConfigurator...  this all seems wrong though.
>>> >
>>>Not necessarily.  If you need to do some stuff before logging gets
>>>configured, it makes perfect sense.  The autoconfiguration probably
>>>should be used if you don't have anything special to do, though.
>>> >-Eric
>>> >
>>> >
>>> >Jacob Kjome wrote:
>>> >
>>> >> Why not use a system property and reference it in your config using
>>> >> usual ${someproperty} syntax.  For instance...
>>> >>
>>> >> ${catalina.home}/logs/mylog.log
>>> >>
>>> >> If you want it to be dynamic per webapp, then you can set the system
>>> >> property in a servlet context listener and then perform the manual
>>> >> configuration of Log4j.
>>> >>
>>> >> And if you are configuring manually via a startup servlet, why put
>>> >> log4j.properties in the classpath?  It would get picked up there
>>> >> automatically anyway (at least under a server using child-first
>>> >> classloading behavior recommended by the servlet spec) assuming
>>> >> log4j.jar is also in WEB-INF/lib.
>>> >>
>>> >> Jake
>>> >>
>>> >> At 05:02 PM 11/11/2004 -0800, you wrote:
>>> >>  >I want to use log4j to configure my webapp to write log files
>>> >>  >it's WEB-INF directory.
>>> >>  >
>>> >>  >Today, I drop a log4j.properties file in WEB-INF/classes and I
>>> >>  >use code in the initialization of a servlet to programmatically
>>>fill in
>>> >>  >the .File property for a FileAppender (or a subclass of FileAppender)
>>> >>  >
>>> >>  >It would be nice if there was a way to specify the dir that the
>>> >>  >pathnames parsed in log4j.properties were relative to or some other
>>> >>  >technique for having the logfiles be relative to the webapp w/out
>>> >>  >writing code.
>>> >>  >
>>> >>  >Any advice?
>>> >>  >
>>> >>  >Thanks,
>>> >>  >-Eric

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message