Yes, a replacement implementation of Jetty's RequestLog interface can be made to construct the access log message in the same format as usual, but to log to a logger rather than directly to a file. This part of the mechanism has already been implemented. The contents of the logged message are not configurable from within the log4j configuration file, but from the RequestLog properties or by hard coding them. In fact, most of the logger configuration would be configured (or even overridden) upon RequestLog instantiation.
The benefit of using log4j is the ability to use appenders. For example, a default file appender with threshold ALL could send all messages to a rotating file, and a JDBC appender could be used for all ERROR level messages (which may have been configured from the RequestLog implementation to be any request that received a 500 level response). In a clustered environment, the addition of a Socket appender could help with log consolidation. I would want to configure each of these loggers from its own log4j configuration file and kept separate from any other configuration that other components may be using. My experience with Log4J is limited so I may be incorrect, but it looks like the static methods usually used to configure and retrieve loggers operate on a classloader-wide basis. I am hoping to localize Logger configuration and access to within an individual RequestLog instance. Would it be better to make an extension of Logger and a specialized Configurator that only reads appender information? -- Center for the Application of Information Technologies ----- Original Message ----- From: "Ceki Gulcu" <[email protected]> To: "Log4J Users List" <[email protected]> Sent: Thursday, March 5, 2009 11:39:55 AM GMT -06:00 US/Canada Central Subject: Re: Separating Configuration Hello, Given that log4j is not designed for access logging, are you really able to do access logging with log4j? Chance Yeoman wrote: > I am working on a log4j implementation of the http request logger for > Jetty 6.1.7 and I had a question about the best practice for > separating logger configurations and hierarchies. I would like to > line configuration up with current Jetty config as much as possible. > This would mean one default logger configured from a single config > file and the ability to create any number of new loggers on a context > basis that could be configured from their own files. What's the best > way to keep these configurations separate and local to the server's > http request logging mechanism? Should I create a LoggerFactory that > maintains it's own LoggerRepository just for the request loggers? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch --------------------------------------------------------------------- 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]
