On Tue, 2005-07-26 at 11:35 -0700, Elias Ross wrote: > On Tue, 2005-07-26 at 09:49 -0700, Mark Palmer wrote: > > > My code and needs to be common/lib (i.e. don't want to > > modify the web application war file in any way) > > > > This means log4j needs to be in common/lib as well. > > This is more of a user question (and a FAQ really), but here's an idea > I'd like to share that's somewhat related. > > You can add a custom appender from a classloader that log4j doesn't see > upon start-up by first loading the base "generic" configuration, and > when your model boots, add the appender to the category/logger tree, > e.g. > > Logger.getRootLogger().addAppender(new MyWarFileAppender()) > > But this gets hard to configure. So, it would be nice to have a model > that allows you to "merge" a log4j.xml file with an existing > configuration. So, you could have: > > log4j.xml (base) > log4j-custom.xml (gets loaded by a servlet) > > And declared categories/appenders etc. would be overlaid onto an > existing configuration rather than replacing the existing configuration > outright. >
Log4j has the ability to be configured with custom repository (hierarchy) selectors. If a Contextual Repository Selector is used then log4j will set up a separate logging enviroment for each distinct Thread Context Class Loader (TCCL) - and each webapp has its own TCCL. The Contextual Repository Selector also looks for the initial log4j configuration files in the TCCL path so that log4j.xml or log4j.properties in the webapp's path will be used instead of the one in the container's path. The container does need to explicitly set up log4j to use such a selector however. See http://www.qos.ch/logging/sc.jsp Note that I don't personally agree with all of Ceki's arguments in the above link. > And maybe people wouldn't feel as compelled to bundle log4j.jar into > every .war deployment... I've never understood this view of the world. A standard servlet or j2ee container has a set of libraries that it is *required* to provide to components. But log4j is *not* part of that set. Therefore components *should* bundle log4j if they want to use it. To me, it's ugly and evil for jars to be added to shared classpaths in a container. The container is the container, and the component is the component, and bits of the component do not belong in the container. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
