logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From donald larmee <dlar...@utopiansoft.com>
Subject Re: Questions re multiple configurations, multiple log files
Date Fri, 18 Oct 2002 19:02:48 GMT
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...


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!
>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' 
>>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...
>>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:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
>>>For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>
>>   donald h. larmee                               dlarmee@utopiansoft.com
>>                          utopian software concepts, inc.
>>                                  www.utopiansoft.com
>>To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
>>For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

   donald h. larmee                               dlarmee@utopiansoft.com
                          utopian software concepts, inc.

To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>

View raw message