logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: Log4j classpath merging?
Date Mon, 05 Apr 2004 17:32:29 GMT
See the version in logging-log4j-sandbox.  Check out the tag mark 0_2_ALPHA (or
something like that).  It will work with Logj4-1.2.8.  I have been using it for
quite a while now with perfect separation of container and multiple webapp
logging under most any appserver.


Quoting Matthew Hunter <matthew@infodancer.org>:

> On Tue, Mar 30, 2004 at 02:24:49PM +0200, Ceki G?lc? <ceki@qos.ch> wrote:
> > We have just added new code to log4j in order to provide a complete
> > solution to the problem you are describing.
> I glanced over the ContextJNDISelector and the accompanying
> examples.  It does look like it is solving the same problem, and
> in a fairly clean way.  However, according to the INSTALL.txt
> file, it will require log4j 1.3, which isn't out yet.  Thus, it
> doesn't effectively solve my problem.
> Of course, "people other than me" have the same problem with
> any solution I contribute, so that's a wash, leaving mainly the
> documentation issue.
> > >I'm using log4j to log application code for several websites,
> > >each of which has at least one WebApp, and some of which have
> > >more than one.  I'm configuring log4j with an initialization
> > >servlet (that also does a few other things) from a properties
> > >file using .configureAndWatch(java.io.File).  I'd like to allow
> > >each webapp to have its own log4j configuration.  The typical
> > >configuration I am using logs to the console with the site name
> > >and webapp name prepended, logs a similar format to a
> > >RollingFileAppender with the file name determined by the site
> > >name, and a SMTPAppender for error notification.
> > >
> > >All of these are working fine, with one small exception...
> > >the configuration of the last properties file loaded is used for
> > >all debug output.  For example, I am expecting to see:
> > >
> > >[www.domainname.com] log message
> > >[www.someothername.com] some other log message
> > >[www.athirddomain.com] yet another log message
> > >
> > >Instead, I'm seeing:
> > >[www.domainname.com] log message
> > >[www.domainname.com] some other log message
> > >[www.domainname.com] yet another log message
> > >
> > >I am using a large amount of common code across these webapps,
> > >so I can't just separate configurations by class name.
> > >
> > >Presently, I'm putting the log4j.jar file in the WEB-INF/lib for
> > >each webapp, and the properties file is in WEB-INF/properties
> > >(eg, not one of the standard log4j locations).  I'm using
> > >log4j-1.2.8; I've seen this problem on both Tomcat 4.1.24 and
> > >5.0.19.
> > >
> > >I found that when I put the log4j.properties file in
> > >WEB-INF/classes/log4j.properties it didn't seem to be found at
> > >all, which is why I moved to this method.  I suspect that if the
> > >log4j code had already initialized itself from somewhere
> > >(perhaps for tomcat internal use?) it wouldn't need to look in
> > >specific webapp classpaths and thus wouldn't pick up the
> > >configuration.
> > >
> > >A bit of googling ran across the class below, which fixes the
> > >problem, except that you have to initialize log4j with that
> > >class, and you can only do so once; subsequent initializations
> > >(eg, with the same initializer servlet in multiple webapps)
> > >either throw ugly errors or could be easily overwritten by any
> > >webapp that disagreed with the idea and wanted to do something
> > >else.
> > >
> >
> > >
> > >Since I had already written a Valve for something else and had
> > >sample code handy, I wrote a Valve to initialize log4j with a
> > >similar policy.  This works and has solved my problem, but leaves
> > >me with three questions:
> > >
> > >1) Is this the way it's supposed to work?  (If so, someone should
> > >fix the log4j documentation).
> >
> > What part of log4j documentation should be fixed?
> > It is not clear to me what you mean by "is the way it's supposed to work?".
> > However, the fact that class loading issues are problematic has been known
> > for quite a while.
> The documentation at the link below claims that if you place the
> log4j.properties under the WEB-INF/classes directory of each
> web-app, that file will be used to initialize the log4j system
> separately for each webapp.  That does not appear to be the case
> for the version of Tomcat 4.0 that I tested; instead, either no
> initializations are loaded, or if a webapp forces the issue (eg,
> by calling configureAndWatch() on a properties file) that
> configuration overrides the configuration for ALL webapps.
> http://logging.apache.org/log4j/docs/manual.html
> This documentation may well have been correct for earlier
> versions of Tomcat.
> I was mainly directing "Is this how it is supposed to work?" at
> Tomcat developers, who presumably should be establishing a
> completely separate classloader for each webapp.  In other words,
> I see this as more of a Tomcat problem than a log4j problem, but
> I could be wrong about that -- I'm hardly an expert on the
> internal workings of either one, much less both.
> > >2) If it's supposed to work this way, then it seems to me that
> > >setting the log4j policy to use separate heirarchies by classpath
> > >should be the default policy.  I can't think of any reason why
> > >one webapp's logging configuration should be able to alter any
> > >other webapp's logging.  Am I wrong?
> > Having separate hierarchies for each web-app is certainly a reasonable
> > policy. However, we are still testing the various implementation of this
> > policy and cannot make it "default" before through testing.
> That's certainly reasonable, but then the documentation should
> say that the feature isn't working yet, or doesn't work on
> certain versions, I would think.
> > >3) If I'm right about 2, is there a better way to do it than a
> > >valve?  Using a valve means I can drop the addition into an
> > >existing configuration, but it seems exceedingly awkward to run
> > >all requests through an extra layer just to get a class loaded
> > >and initialized once-and-only-once with no webapp dependencies.
> > >Is there a better construct for this sort of thing?
> >
> > What does the valve do? I'd be interested to study in the code.
> The only thing the valve does is initialize log4j with the
> ContextClassLoaderSelector when Tomcat itself is initialized
> (and hence initializes the valve).  This ensures that even with
> separate classloaders we have a once-and-once-only initialization
> of the log4j selector that occurs before any of the webapps have
> a chance to confuse the issue.
> The class is located temporarily at:
> http://www.infodancer.org/software/Log4jSeparatorValve.java
> Note that at the present it depends on a version of
> ContextClassLoaderSelector within the same package, so I don't
> have the external dependency, but no significant changes were
> made otherwise.  That version is here:
> http://www.infodancer.org/software/ContextClassLoaderSelector.java
> It would be trivial to make the selector class parameterizable.
> For the valve to work it must be able to find the log4j classes;
> dropping them in common/lib seems simplest.  There should
> also be a configuration file in server/classes/log4j.properties
> to control how Tomcat's internal logging works.
> The config file needs this line:
> <Valve className="org.infodancer.servlet.Log4jSeparatorValve" />
> It must be noted that this code is very raw, not very well
> tested, and certainly not release-quality.  However, it's working
> for me at the moment.
> > >4) If there's interest I'd gladly contribute the valve to the
> > >apache codebase so others can just modify their server.xml rather
> > >than writing code; is there any interest in doing that?
> > Please do. We should perhaps continue this discussion in log4j-dev@logging.
> I've redirected it there.
> While I'm perfectly willing to contribute this, I haven't done
> any apache contributions before and have absolutely no idea what
> hoops need to be jumped through.  And of course there's no point
> if this particular problem can be solved in a cleaner way, as
> the JNDI class seems to do.  If there's interest, I'll do a bit
> of cleaning and polishing on this solution and contribute it;
> just point me in the right direction.
> --
> Matthew Hunter (matthew@infodancer.org)
> Public Key: http://matthew.infodancer.org/public_key.txt
> Homepage: http://matthew.infodancer.org/index.jsp
> Politics: http://www.triggerfinger.org/index.jsp
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message