You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jacob Kjome <ho...@visi.com> on 2004/11/12 06:14:34 UTC
Re: best practice question: webapp relative filenames in
FileAppenders
Why not use a system property and reference it in your config using the
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 underneath
>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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: best practice question: webapp relative filenames in FileAppenders
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Eric Bloch <bl...@laszlosystems.com>:
> Jacob,
>
> 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).
>
Yes, but since the property name is predictable, you can add it to your security
policy just like you can refrence it in your config file.
> Do you know if the servlet spec guarentee that the log4j properties file
> will be loaded *after* the listener is called?
>
Well, the listener calls another class which does all the work. And that class
sets the system property before it runs configuration. Otherwise, there would
be very little point to this exercise (and you should not have your config file
in the classpath). Keep in mind that you need to set up a few things in your
web.xml before using this (above and beyond simply declaring the listener).
BTW, the other advantage of all this is that it provides for using a custom
RepositorySelector (also in logging-log4j-sandbox) which you configure (unless
someone set it at server startup, in which case that one would be used) which
allows you to have a global log4j (in common/lib), but separate logging between
applications. This is all integrated in the servlet context listener set up.
Check out logging-log4j-sandbox with the alpha3 tag (look up the tag, can't
remember exactly how I declared it, but it should be obvious), build the jar,
and run javadoc (all part of the ant script... and make sure to set up your
buld.properties to put the servlet jar and other dependencies in there so the
build knows about them before creating the jar). The Javadoc should describe
all you need to do to get things up and running. Remember to use the
ContextJNDISelector, not the ContextClassLoaderSelector. The latter is evil in
a should probably be removed from CVS. When using this, make sure the sandbox
jar is always in the same location as the log4j jar. If you put log4j.jar in
WEB-INF/lib, then you should do the same with the sandbox jar. If you put
log4j.jar in common/lib, then do the same with the sandbox jar.
Any other questions, let me know.
Jake
> -Eric
>
>
> Jacob Kjome wrote:
>
> > Quoting Eric Bloch <bl...@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.
> >>>
> >>>
> >>>Jake
> >>>
> >>> >-Eric
> >>> >
> >>> >
> >>> >Jacob Kjome wrote:
> >>> >
> >>> >> Why not use a system property and reference it in your config using
> the
> >>> >> 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
> >>>underneath
> >>> >> >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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: best practice question: webapp relative filenames in FileAppenders
Posted by Eric Bloch <bl...@laszlosystems.com>.
Jacob,
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?
-Eric
Jacob Kjome wrote:
> Quoting Eric Bloch <bl...@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.
>>>
>>>
>>>Jake
>>>
>>> >-Eric
>>> >
>>> >
>>> >Jacob Kjome wrote:
>>> >
>>> >> Why not use a system property and reference it in your config using the
>>> >> 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
>>>underneath
>>> >> >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
Re: best practice question: webapp relative filenames in FileAppenders
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Eric Bloch <bl...@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.
> >
> >
> > Jake
> >
> > >-Eric
> > >
> > >
> > >Jacob Kjome wrote:
> > >
> > >> Why not use a system property and reference it in your config using the
> > >> 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
> > underneath
> > >> >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
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: best practice question: webapp relative filenames in FileAppenders
Posted by Eric Bloch <bl...@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.
> 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?
>
> >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.
>
>
> Jake
>
> >-Eric
> >
> >
> >Jacob Kjome wrote:
> >
> >> Why not use a system property and reference it in your config using the
> >> 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
> underneath
> >> >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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: best practice question: webapp relative filenames in
FileAppenders
Posted by Jacob Kjome <ho...@visi.com>.
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.
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
>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.
Jake
>-Eric
>
>
>Jacob Kjome wrote:
>
>> Why not use a system property and reference it in your config using the
>> 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 underneath
>> >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
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: best practice question: webapp relative filenames in FileAppenders
Posted by Eric Bloch <bl...@laszlosystems.com>.
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.
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.
-Eric
Jacob Kjome wrote:
> Why not use a system property and reference it in your config using the
> 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 underneath
> >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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org