See inline...
HTH
|-----Original Message-----
|From: Scott Heaberlin [mailto:[EMAIL PROTECTED]]
|Sent: Tuesday, February 18, 2003 5:12 PM
|To: [EMAIL PROTECTED]
|Subject: Multiple application log files
|
|
|Hello all -
|
|I am new to the log4j users list, so forgive me if I
|am asking something answered many times before. I did
|search the list archives before sending this, and
|didn't see any matches to my search but I realize I
|simply may have searched on the wrong queries...
|
|My question is as follows:
|
|We recently decided to use Log4J for our website
|application logging. Here is what I am looking to do:
|
|We have several separate "applications" which use both
|application specific code as well as code in shared
|jar/class libraries. The behavior we'd like is to
|have all code executed by application X to go to, say,
|X.log while all code executed by application Y to go
|to Y.log.
|
|For example, application A executes code in
|com.foo.SharedClass which logs to what I believe is
|the root logger ( Logger.getLogger(SharedClass.class)
|). Application A must log to A.log, including all
|logging from A specific classes as well as logging
|from shared code executed during A. Application B, on
|the other hand, must log in the same manner to B.log,
|including B specific code and shared code logging
|output during the course of B's execution.
|
Reasonable enough for requirements...
|All in all, a fairly simple concept. But here are the
|restrictions:
|
|1) Our applications are not in standard J2EE web-app
|structure (webapps\appName\WEB-INF, web.xml, etc).
|Basically what we refer to as a separate application
|is treated by the server as merely a different virtual
|subdirectory. So, we don't have the luxury of a
|1-to-1 app to subdir ratio (and therefore 1-to-1 app
|to log file).
|
It is not so much the app to subdir issue, as a classloader creation issue.
The whole reason behind defining seperate J2EE apps is to acheive seperate
classloader instances for each defined app. That is where you will most
feel this pain, because a lot of interesting things are possible because of
these seperate classloaders. For example, when you specify the
"log4j.config" sys-prop for initialization, log4j will use its classloader
to attempt to load that resource. Now if each app is using a seperate
classloader then each app could have its own version of the log4j config
file. But obviously, that wont be possible with the setup you describe.
|2) If we can accomplish this via configuration file,
|we must use a *single* configuration file for all
|apps. I realize that if each "app" (each having its
|own startup servlet for intialization) could use
|separate log4j config files each containing the
|correct log file location, but we are limited to a
|single config file.
|
Really, based on what you mention, I dont see any other (viable) way here.
Configuration of all loggers, all appenders, etc. for all apps would have to
be in one configuration file. Then you would need to use some kind of
ThreadLocal-based solution like NDC or MDC or a custom one in order to
determine the "web-app" from which the request came. Is there a controller
servlet in your set up? Is this one per app? Or one for all apps? You
could set up the ThreadLocal variables there based on the incoming "web-app"
request. Or something similiar could be acheived using the servlet filter
concept.
What deferentiates your "web-apps"? URLs? So something like
"/appA/somePage" and "/appB/somePage"?
|Our original thought was to create named Loggers
|(Logger.getLogger("applicationA")) when each app's
|startup servlet executes init(), but we weren't sure
|how the common code would use these loggers. I have
|been reading about the NDC/MDC classes and their
|ability to automatically "tag" each log statement in a
|particular path of execution for later ease of
|differentiation. Obviously we could use
|NDC.push("application_A") calls in each page/servlet
|of application A, but this alone doesn't achieve our
|goal of having separate logs per application.
|Separate appenders can output to different places via
|different methods, but can we somehow specify which
|appender to use through each execution context?
|
The piece you are missing is filters. It would be possible to filter
certain log messages based upon NDC/MDC values. Assuming you want
_EVERYTHING_ logged to go into these app-specific files, then define your
root-logger with all possible app-specific appenders attached to it. Then
attach filters to the app-specific appenders to look for the NDC/MDC info
they are interested in.
|Any thoughts/links/RTFMs are much appreciated.
|
|
|Sincerely,
|
|Scott Heaberlin
|
|
|
|__________________________________________________
|Do you Yahoo!?
|Yahoo! Shopping - Send Flowers for Valentine's Day
|http://shopping.yahoo.com
|
|-----------------------------------------------------------
|----------
|To unsubscribe, e-mail: [EMAIL PROTECTED]
|For additional commands, e-mail: [EMAIL PROTECTED]
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
