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>
