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 Chris Bailey <ch...@codeintensity.com> on 2002/10/17 20:16:19 UTC
Questions re multiple configurations, multiple log files
I have an application, or rather, set of applications that use log4j
extensively for logging. In general, there is a "service" wrapper on each
application, and then the app. What I wanted was for the service to have a
log4j config file and do it's logging based on that, and then the
application to have a log4j config file of its own and write to the files
specified by that. But, it appears that when the application does it's
log4j configuration, that supersedes the service's log4j config, so now the
service is writing all its messages to the app's log files. Is that
correct - is there only one config of log4j per VM instance? I believe this
is true because they use the same classloader and thus the same static log4j
instances, etc.
I am already using NDC's within the application. Is it possible to achieve
what I want, in a single VM/classloader, or do I basically have to use a
single config file and then separate out my logging messages based on NDC
and/or Logger name, etc.?
Also, we have multiple instances of this kind of thing, not of the app's
themselves, but of the service component (which is a generic wrapper that is
used across each app). Each one runs in a separate VM, but they write to
the same log file. Is that a problem?
It seems that I may have to rethink this and use a single config file as
well as single log file (of a given type, e.g. text file), and then just
differentiate the log messages within that log file.
__
Chris Bailey mailto:chris@codeintensity.com
Code Intensity http://www.codeintensity.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Questions re multiple configurations, multiple log files
Posted by Jacob Kjome <ho...@visi.com>.
Thanks Don,
Yes, that definitely does help. It is nice to know what design has worked
for someone else. I'll try to implement this in Tomat.
I remember that someone suggested a standard Log4jInit servlet be included
in the Log4j package since so many people need it. Might I suggest the
same here? A standard repository selector and examples of its usage would
go a long way to reducing the "how do I use Log4j in an application server"
questions.
Jake
At 03:02 PM 10/18/2002 -0400, you wrote:
>Your situation might be a little different than mine (I am not using
>CATALINA, but rather a custom mini-AppServer...),so YMMV a bit...
>
>Well, you certainly could keep a handle to the original CRS object... but
>there are some other options as well:
>
>- I use a WeakHashMap to store the Hierarchies in, which (in theory) will
>automagically remove entries when the keys in question are no longer in
>use (i.e., if you use the Contextual ClassLoader as your key, when the
>'Application' goes away, the entry will (eventually) automatically be
>removed when the system garbage collects. So I generally do not worry
>about explicitly removing the entries.
>
>- In addition, I implemented my CRS as a Singleton, with a lone instance
>retrievable by calling a static getInstance() method... so you don't
>necessarily need to save an explicit handle, as you can obtain a handle to
>the lone instance via the factory method. (I also allow for a 'reset' that
>forces the creation of a new CRS object, that overlays the existing
>instance... once this happens, if you don't have a handle to the original
>you may be SOL.) Making the CRS a singleton was primarily done so I
>could get access to the Map that contains the Repositories so they could
>be exposed via JMX
>
>Does this answer your question?
>
>OK, hope it helps...
>
>-don
>
>
>At 10:25 PM 10/17/2002 -0500, Jacob Kjome wrote:
>
>>I am very interested in learning how you implemented you
>>RepositorySelector. I posted a question about this the other day but got
>>no response. I put the RespostorySelector described by Ceki's article
>>in $CATALINA_HOME/shared/lib and inited it as he described my my app's
>>Log4jInit servlet. However, I'm unclear as to how to unregister that
>>Repository. I need a handle to the original CRS object to call remove()
>>on it and I'm unclear as to how that is done.
>>
>>If you can provide instruction on how you implemented things, I would be
>>very grateful!
>>
>>Jake
>>
>>At 05:44 PM 10/17/2002 -0400, you wrote:
>>>Re: Multiple config files...
>>>I have recently had to solve the same problem.. i.e., I have an
>>>AppServer (of sorts) that needs its own log4j configuration, and then
>>>some number of applications that will run 'inside' the AppServer, each
>>>of which is to have its own configuration file.
>>>
>>>The solution I implemented was to install a custom RepositorySelector
>>>that doles out Hierarchies based upon the Context of the ClassLoader of
>>>the caller. Each app has its own Context (the AppServer included) and
>>>so each gets its own log4j 'partition' within the same JVM. This
>>>approach is fairly easily accomplished.... the biggest issue I had was
>>>getting the various Apps/AppServer to find the correct version of the
>>>standard 'log4j.properties' file (We did not want to mandate an explicit
>>>call to a Configurator...preferring to let the apps in question
>>>'autoconfigure' themselves.
>>>
>>>So the forcing of the Applications to 'prefer' their default
>>>log4j.properties files that resided in their local ClassPath, over the
>>>default AppServer log4j.properties file, proved tricky as this behavior
>>>runs contrary to the standard Delegation model of the ClassLoader. I can
>>>provide more info on how I accomplished this if interested.
>>>
>>>Check the log4j-dev archives, as I believe this is the same basic
>>>approach that the jBoss folks have (apparently) taken. Also checkout
>>>http://www.qos.ch/containers/sc.html for a good description of the
>>>problem, and the equivalent solution. ( I found this link whilst
>>>researching the issue)
>>>
>>>Re: Multiple VMs writing to the same file...
>>>
>>>I am assuming you are using a FileAppender of some sort... this almost
>>>certainly not work, as the native OS in question will likely not
>>>interleave the simultaneous file access safely/properly... i.e., the
>>>last VM to write to the file in question will 'win'... and overwrite the
>>>previous data. However, you can choose a different Appender that has
>>>MUX type of capabilities however... like JMS or Socket appenders...
>>>where you have a dedicated process listening on a Queue/Socket and
>>>consodating the logging messages in a FIFO manner (ala Unix's syslogd)
>>>
>>>Hope it helps...
>>>
>>>-don
>>>
>>>At 11:16 AM 10/17/2002 -0700, Chris Bailey wrote:
>>>>I have an application, or rather, set of applications that use log4j
>>>>extensively for logging. In general, there is a "service" wrapper on each
>>>>application, and then the app. What I wanted was for the service to have a
>>>>log4j config file and do it's logging based on that, and then the
>>>>application to have a log4j config file of its own and write to the files
>>>>specified by that. But, it appears that when the application does it's
>>>>log4j configuration, that supersedes the service's log4j config, so now the
>>>>service is writing all its messages to the app's log files. Is that
>>>>correct - is there only one config of log4j per VM instance? I believe
>>>>this
>>>>is true because they use the same classloader and thus the same static
>>>>log4j
>>>>instances, etc.
>>>>
>>>>I am already using NDC's within the application. Is it possible to achieve
>>>>what I want, in a single VM/classloader, or do I basically have to use a
>>>>single config file and then separate out my logging messages based on NDC
>>>>and/or Logger name, etc.?
>>>>
>>>>Also, we have multiple instances of this kind of thing, not of the app's
>>>>themselves, but of the service component (which is a generic wrapper
>>>>that is
>>>>used across each app). Each one runs in a separate VM, but they write to
>>>>the same log file. Is that a problem?
>>>>
>>>>It seems that I may have to rethink this and use a single config file as
>>>>well as single log file (of a given type, e.g. text file), and then just
>>>>differentiate the log messages within that log file.
>>>>
>>>>__
>>>>Chris Bailey mailto:chris@codeintensity.com
>>>>Code Intensity http://www.codeintensity.com
>>>>
>>>>
>>>>--
>>>>To unsubscribe,
>>>>e-mail: <ma...@jakarta.apache.org>
>>>>For additional commands, e-mail:
>>>><ma...@jakarta.apache.org>
>>>
>>>
>>>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
>>> donald h. larmee dlarmee@utopiansoft.com
>>>804.301.UTOP
>>> utopian software concepts, inc.
>>> www.utopiansoft.com
>>>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
>>>
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> donald h. larmee dlarmee@utopiansoft.com
>
>804.301.UTOP
> utopian software concepts, inc.
> www.utopiansoft.com
>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Questions re multiple configurations, multiple log files
Posted by donald larmee <dl...@utopiansoft.com>.
Your situation might be a little different than mine (I am not using
CATALINA, but rather a custom mini-AppServer...),so YMMV a bit...
Well, you certainly could keep a handle to the original CRS object... but
there are some other options as well:
- I use a WeakHashMap to store the Hierarchies in, which (in theory) will
automagically remove entries when the keys in question are no longer in use
(i.e., if you use the Contextual ClassLoader as your key, when the
'Application' goes away, the entry will (eventually) automatically be
removed when the system garbage collects. So I generally do not worry
about explicitly removing the entries.
- In addition, I implemented my CRS as a Singleton, with a lone instance
retrievable by calling a static getInstance() method... so you don't
necessarily need to save an explicit handle, as you can obtain a handle to
the lone instance via the factory method. (I also allow for a 'reset' that
forces the creation of a new CRS object, that overlays the existing
instance... once this happens, if you don't have a handle to the original
you may be SOL.) Making the CRS a singleton was primarily done so I
could get access to the Map that contains the Repositories so they could be
exposed via JMX
Does this answer your question?
OK, hope it helps...
-don
At 10:25 PM 10/17/2002 -0500, Jacob Kjome wrote:
>I am very interested in learning how you implemented you
>RepositorySelector. I posted a question about this the other day but got
>no response. I put the RespostorySelector described by Ceki's article in
>$CATALINA_HOME/shared/lib and inited it as he described my my app's
>Log4jInit servlet. However, I'm unclear as to how to unregister that
>Repository. I need a handle to the original CRS object to call remove()
>on it and I'm unclear as to how that is done.
>
>If you can provide instruction on how you implemented things, I would be
>very grateful!
>
>Jake
>
>At 05:44 PM 10/17/2002 -0400, you wrote:
>>Re: Multiple config files...
>>I have recently had to solve the same problem.. i.e., I have an AppServer
>>(of sorts) that needs its own log4j configuration, and then some number
>>of applications that will run 'inside' the AppServer, each of which is to
>>have its own configuration file.
>>
>>The solution I implemented was to install a custom RepositorySelector
>>that doles out Hierarchies based upon the Context of the ClassLoader of
>>the caller. Each app has its own Context (the AppServer included) and so
>>each gets its own log4j 'partition' within the same JVM. This approach
>>is fairly easily accomplished.... the biggest issue I had was getting the
>>various Apps/AppServer to find the correct version of the standard
>>'log4j.properties' file (We did not want to mandate an explicit call to a
>>Configurator...preferring to let the apps in question 'autoconfigure'
>>themselves.
>>
>>So the forcing of the Applications to 'prefer' their default
>>log4j.properties files that resided in their local ClassPath, over the
>>default AppServer log4j.properties file, proved tricky as this behavior
>>runs contrary to the standard Delegation model of the ClassLoader. I can
>>provide more info on how I accomplished this if interested.
>>
>>Check the log4j-dev archives, as I believe this is the same basic
>>approach that the jBoss folks have (apparently) taken. Also checkout
>>http://www.qos.ch/containers/sc.html for a good description of the
>>problem, and the equivalent solution. ( I found this link whilst
>>researching the issue)
>>
>>Re: Multiple VMs writing to the same file...
>>
>>I am assuming you are using a FileAppender of some sort... this almost
>>certainly not work, as the native OS in question will likely not
>>interleave the simultaneous file access safely/properly... i.e., the last
>>VM to write to the file in question will 'win'... and overwrite the
>>previous data. However, you can choose a different Appender that has
>>MUX type of capabilities however... like JMS or Socket appenders... where
>>you have a dedicated process listening on a Queue/Socket and consodating
>>the logging messages in a FIFO manner (ala Unix's syslogd)
>>
>>Hope it helps...
>>
>>-don
>>
>>At 11:16 AM 10/17/2002 -0700, Chris Bailey wrote:
>>>I have an application, or rather, set of applications that use log4j
>>>extensively for logging. In general, there is a "service" wrapper on each
>>>application, and then the app. What I wanted was for the service to have a
>>>log4j config file and do it's logging based on that, and then the
>>>application to have a log4j config file of its own and write to the files
>>>specified by that. But, it appears that when the application does it's
>>>log4j configuration, that supersedes the service's log4j config, so now the
>>>service is writing all its messages to the app's log files. Is that
>>>correct - is there only one config of log4j per VM instance? I believe this
>>>is true because they use the same classloader and thus the same static log4j
>>>instances, etc.
>>>
>>>I am already using NDC's within the application. Is it possible to achieve
>>>what I want, in a single VM/classloader, or do I basically have to use a
>>>single config file and then separate out my logging messages based on NDC
>>>and/or Logger name, etc.?
>>>
>>>Also, we have multiple instances of this kind of thing, not of the app's
>>>themselves, but of the service component (which is a generic wrapper that is
>>>used across each app). Each one runs in a separate VM, but they write to
>>>the same log file. Is that a problem?
>>>
>>>It seems that I may have to rethink this and use a single config file as
>>>well as single log file (of a given type, e.g. text file), and then just
>>>differentiate the log messages within that log file.
>>>
>>>__
>>>Chris Bailey mailto:chris@codeintensity.com
>>>Code Intensity http://www.codeintensity.com
>>>
>>>
>>>--
>>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
>> donald h. larmee dlarmee@utopiansoft.com
>>804.301.UTOP
>> utopian software concepts, inc.
>> www.utopiansoft.com
>>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
donald h. larmee dlarmee@utopiansoft.com
804.301.UTOP
utopian software concepts, inc.
www.utopiansoft.com
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Questions re multiple configurations, multiple log files
Posted by Jacob Kjome <ho...@visi.com>.
I am very interested in learning how you implemented you
RepositorySelector. I posted a question about this the other day but got
no response. I put the RespostorySelector described by Ceki's article in
$CATALINA_HOME/shared/lib and inited it as he described my my app's
Log4jInit servlet. However, I'm unclear as to how to unregister that
Repository. I need a handle to the original CRS object to call remove() on
it and I'm unclear as to how that is done.
If you can provide instruction on how you implemented things, I would be
very grateful!
Jake
At 05:44 PM 10/17/2002 -0400, you wrote:
>Re: Multiple config files...
>I have recently had to solve the same problem.. i.e., I have an AppServer
>(of sorts) that needs its own log4j configuration, and then some number of
>applications that will run 'inside' the AppServer, each of which is to
>have its own configuration file.
>
>The solution I implemented was to install a custom RepositorySelector
>that doles out Hierarchies based upon the Context of the ClassLoader of
>the caller. Each app has its own Context (the AppServer included) and so
>each gets its own log4j 'partition' within the same JVM. This approach is
>fairly easily accomplished.... the biggest issue I had was getting the
>various Apps/AppServer to find the correct version of the standard
>'log4j.properties' file (We did not want to mandate an explicit call to a
>Configurator...preferring to let the apps in question 'autoconfigure'
>themselves.
>
>So the forcing of the Applications to 'prefer' their default
>log4j.properties files that resided in their local ClassPath, over the
>default AppServer log4j.properties file, proved tricky as this behavior
>runs contrary to the standard Delegation model of the ClassLoader. I can
>provide more info on how I accomplished this if interested.
>
>Check the log4j-dev archives, as I believe this is the same basic approach
>that the jBoss folks have (apparently) taken. Also checkout
>http://www.qos.ch/containers/sc.html for a good description of the
>problem, and the equivalent solution. ( I found this link whilst
>researching the issue)
>
>Re: Multiple VMs writing to the same file...
>
>I am assuming you are using a FileAppender of some sort... this almost
>certainly not work, as the native OS in question will likely not
>interleave the simultaneous file access safely/properly... i.e., the last
>VM to write to the file in question will 'win'... and overwrite the
>previous data. However, you can choose a different Appender that has
>MUX type of capabilities however... like JMS or Socket appenders... where
>you have a dedicated process listening on a Queue/Socket and consodating
>the logging messages in a FIFO manner (ala Unix's syslogd)
>
>Hope it helps...
>
>-don
>
>At 11:16 AM 10/17/2002 -0700, Chris Bailey wrote:
>>I have an application, or rather, set of applications that use log4j
>>extensively for logging. In general, there is a "service" wrapper on each
>>application, and then the app. What I wanted was for the service to have a
>>log4j config file and do it's logging based on that, and then the
>>application to have a log4j config file of its own and write to the files
>>specified by that. But, it appears that when the application does it's
>>log4j configuration, that supersedes the service's log4j config, so now the
>>service is writing all its messages to the app's log files. Is that
>>correct - is there only one config of log4j per VM instance? I believe this
>>is true because they use the same classloader and thus the same static log4j
>>instances, etc.
>>
>>I am already using NDC's within the application. Is it possible to achieve
>>what I want, in a single VM/classloader, or do I basically have to use a
>>single config file and then separate out my logging messages based on NDC
>>and/or Logger name, etc.?
>>
>>Also, we have multiple instances of this kind of thing, not of the app's
>>themselves, but of the service component (which is a generic wrapper that is
>>used across each app). Each one runs in a separate VM, but they write to
>>the same log file. Is that a problem?
>>
>>It seems that I may have to rethink this and use a single config file as
>>well as single log file (of a given type, e.g. text file), and then just
>>differentiate the log messages within that log file.
>>
>>__
>>Chris Bailey mailto:chris@codeintensity.com
>>Code Intensity http://www.codeintensity.com
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> donald h. larmee dlarmee@utopiansoft.com
>
>804.301.UTOP
> utopian software concepts, inc.
> www.utopiansoft.com
>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Questions re multiple configurations, multiple log files
Posted by donald larmee <dl...@utopiansoft.com>.
Re: Multiple config files...
I have recently had to solve the same problem.. i.e., I have an AppServer
(of sorts) that needs its own log4j configuration, and then some number of
applications that will run 'inside' the AppServer, each of which is to have
its own configuration file.
The solution I implemented was to install a custom RepositorySelector that
doles out Hierarchies based upon the Context of the ClassLoader of the
caller. Each app has its own Context (the AppServer included) and so each
gets its own log4j 'partition' within the same JVM. This approach is
fairly easily accomplished.... the biggest issue I had was getting the
various Apps/AppServer to find the correct version of the standard
'log4j.properties' file (We did not want to mandate an explicit call to a
Configurator...preferring to let the apps in question 'autoconfigure'
themselves.
So the forcing of the Applications to 'prefer' their default
log4j.properties files that resided in their local ClassPath, over the
default AppServer log4j.properties file, proved tricky as this behavior
runs contrary to the standard Delegation model of the ClassLoader. I can
provide more info on how I accomplished this if interested.
Check the log4j-dev archives, as I believe this is the same basic approach
that the jBoss folks have (apparently) taken. Also checkout
http://www.qos.ch/containers/sc.html for a good description of the problem,
and the equivalent solution. ( I found this link whilst researching the issue)
Re: Multiple VMs writing to the same file...
I am assuming you are using a FileAppender of some sort... this almost
certainly not work, as the native OS in question will likely not interleave
the simultaneous file access safely/properly... i.e., the last VM to write
to the file in question will 'win'... and overwrite the previous
data. However, you can choose a different Appender that has MUX type of
capabilities however... like JMS or Socket appenders... where you have a
dedicated process listening on a Queue/Socket and consodating the logging
messages in a FIFO manner (ala Unix's syslogd)
Hope it helps...
-don
At 11:16 AM 10/17/2002 -0700, Chris Bailey wrote:
>I have an application, or rather, set of applications that use log4j
>extensively for logging. In general, there is a "service" wrapper on each
>application, and then the app. What I wanted was for the service to have a
>log4j config file and do it's logging based on that, and then the
>application to have a log4j config file of its own and write to the files
>specified by that. But, it appears that when the application does it's
>log4j configuration, that supersedes the service's log4j config, so now the
>service is writing all its messages to the app's log files. Is that
>correct - is there only one config of log4j per VM instance? I believe this
>is true because they use the same classloader and thus the same static log4j
>instances, etc.
>
>I am already using NDC's within the application. Is it possible to achieve
>what I want, in a single VM/classloader, or do I basically have to use a
>single config file and then separate out my logging messages based on NDC
>and/or Logger name, etc.?
>
>Also, we have multiple instances of this kind of thing, not of the app's
>themselves, but of the service component (which is a generic wrapper that is
>used across each app). Each one runs in a separate VM, but they write to
>the same log file. Is that a problem?
>
>It seems that I may have to rethink this and use a single config file as
>well as single log file (of a given type, e.g. text file), and then just
>differentiate the log messages within that log file.
>
>__
>Chris Bailey mailto:chris@codeintensity.com
>Code Intensity http://www.codeintensity.com
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
donald h. larmee dlarmee@utopiansoft.com
804.301.UTOP
utopian software concepts, inc.
www.utopiansoft.com
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>