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: <mailto:log4j-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@;jakarta.apache.org>
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ donald h. larmee [EMAIL PROTECTED] 804.301.UTOP 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 [EMAIL PROTECTED] 804.301.UTOP 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>
