Add an implementation of RequestLog that supports Log4j

You should have a look at logback, in particular logback-access which has support for access logging in Jetty.

http://logback.qos.ch/
http://logback.qos.ch/access.html

Excellent,
I quickly browsed through the logback documentation, and it looks like it can be a nice fit.
As in: slf4j -> logback -> log4j (if people want log4j)
But slf4j -> logback implements a lot already, including a syslogAppender, and socketAppender.

The example of ch.qos.logback.classic.net.SimpleSocketServer at http://logback.qos.ch/manual/appenders.html#SocketAppender describes how to set up the receiving server for socketAppender log events.

However, I read this:
-
If you stop and restart the SimpleSocketServer the client will transparently reconnect to the new server instance, although the events generated while disconnected will be simply (and irrevocably) lost.
-
So the socketAppender and SimpleSocketServer cannot be a final solution.
I see how to write our own appenders. Perhaps, if desired, one can extend the socketAppender to queue the log events in a fifo queue acting as a buffer.

But definitely I can see how the SimpleSocketServer can be turned into a Geronimo gbean, and launched as a resource service to centralize logging.

Thanks for the pointing.
I think this is a good direction to go.

Hi Russell,

If you have any specific question about an logback or logback-access do not hesitate to ask on the logback user list.

This JIRA issue could potentially be resolved if Jetty6 includes logback in it's distribution.
Main Site: http://logback.qos.ch/

It has been found that the Logback distribution already contains an implementation of JettyRequestLog which seems to satisfy this issue.
The class, ch.qos.logback.access.jetty.RequestLogImpl, is distributed in all logback 0.9.x releases.

Documentation: http://logback.qos.ch/access.html#jetty

It is implemented in Jetty with this configuration:

• $JETTY_HOME/etc/jetty.xml -
  <Ref id="requestLog">
  <Set name="requestLog">
  <New id="requestLogImpl"
  class="ch.qos.logback.access.jetty.RequestLogImpl">
  </New>
  </Set>
  </Ref>
  -
  And this configuration uses a configuration file:
  $JETTY_HOME/etc/logback-access.xml

-
As side notes, it appears that:
1. logback 0.9.6 supports slf4j 1.3.0
2. logback 0.9.7 supports slf4j 1.4.0
3. logback 0.9.8 supports slf4j 1.4.0
4. logback 0.9.9 supports slf4j 1.4.3
5. The latest logback, 0.9.14, supports slf4j 1.5.6

And additionally:
1. Jetty 6.1.14 appears to implement slf4j 1.3.1 - so it should support logback 0.9.6
2. Geronimo-Jetty 2.1.3 (Jetty 6.1.7) implements slf4j 1.4.3 - so it should support logback 0.9.9

It would be nice if jetty shipped with logback but I don't think that would happen in the short term. However, adding a a reference to logback in the relevant jetty documentation [1] could be done easily and would be very helpful. I'd be happy yo add it.

[1] http://docs.codehaus.org/display/JETTY/Logging+Requests

Ceki,

Reference to LogBack and the Jetty request logger duly added to the jetty wiki page:
http://docs.codehaus.org/display/JETTY/Logging+Requests.

cheers
Jan

I think it is best to include logback into the Jetty distribution.
It would open a whole new realm of possibilities for Jetty Logging, by simply adding the library.

logback uses slf4j

Jetty 6.1.14 implements slf4j 1.3.1
jetty-6.1.14/lib/jsp-2.0/jcl104-over-slf4j-1.3.1.jar
jetty-6.1.14/lib/jsp-2.0/slf4j-api-1.3.1.jar
jetty-6.1.14/lib/jsp-2.0/slf4j-simple-1.3.1.jar

Jetty 7.0.0.pre5 removes jsp-2.0 support which contains the slf4j libraries in Jetty6.
Some libraries were rencarnated into the lib/wadi directory:
-
jetty-7.0.0.pre5/lib/wadi/jcl104-over-slf4j-1.0.1.jar
jetty-7.0.0.pre5/lib/wadi/slf4j-simple-1.0.1.jar
-
But it is slf4j version 1.0.1, and the slf4j-api library is not present.
Why does Jetty 7 not include the slf4j from Jetty6, but a lower version 1.0.1?
Perhaps this should be submitted as another issue?

And actually, Jetty6's jsp-2.0 contained libraries for jasper, xercesImpl, and xmlParserAPIs, all which are not found in the Jetty 7.0.0.pre5

Jetty6 could upgrade the slf4j library.
Geronimo 2.1.3 uses Jetty 6.1.7, and it implement this combination with slf4j 1.4.3 .

Hello Jan,

I have taken the liberty of modifying the paragraph you added. The modified paragraph now reads:

The logback project offers another implementation of RequestLog interface
providing very rich and powerful HTTP-access log functionality,

I hope you will find the changes acceptable.

After a very good discussion on the matter of bundling 3rd party libraries into Jetty, http://www.nabble.com/-DISCUSS--Jetty-6.2-or-7.0-for-new-features--td21627534.html , my team has decided to take another look at implementing this "New Feature" request using Log4j.
Mainly since log4j is APL, the same as Jetty.

We still support the use of Logback, and will continue working in that area for Jetty and Geronimo.
After Jetty transitions to The Eclipse Foundation, perhaps we can take another look at Logback.

-RG

assigning to myself to keep this on the radar

I checked with eclipse and logback is not apparently an allowed dependency, but once we are in we can make requests...so I'll keep on this issue and look into that when we are there, hopefully soon

We have created two implementations of RequestLog for Geronimo-Jetty.
1) uses the existing Logback implementation of Jetty RequestLog
2) reimplements the NCSARequestLog as Log4j, so the there is an ability to add LogAppenders - it could be a replacement for the NCSARequestLog, if desired.

We are in the process of testing them both.
-RG

A very simple Log4J RequestLog implementation has been made, but I will have to modify the way it creates message strings to build with Java 1.4. Am I correct in thinking that this component would be required to be Java 1.4 compatible?

Chance

jetty6 is 1.4 requirement for that component, and then jetty7 is 1.5 required

Ok. For the Jetty6 version, I'll just build the message string in the same way as the NCSARequestLog.

I have been a bit held up with this as I wanted to make sure that I didn't run into any collision trouble with any web applications that also use Log4J with different configuration and possibly different versions. The only solution that I could come up with was to setup a separate class loader for server logging (currently only access logging) and to load and configure the Log4J classes in that sandbox. I seems to work fine, but the bad news is that it now requires the log4j jar and one other jar to not be included on the server class path, but to be configured in jetty.xml. For example, if the default file locations are not used, the following config would be needed in jetty.xml to enable log4j for the server:

<Call class="org.mortbay.jetty.JettyServerLog4JConfig" name="setLog4JJarPath">
<Arg><SystemProperty name="jetty.home" default="."/>/lib/log4j/log4j-1.2.14.jar</Arg>
</Call>
<Call class="org.mortbay.jetty.JettyServerLog4JConfig" name="setLog4JImplJarPath">
<Arg><SystemProperty name="jetty.home" default="."/>/lib/log4j/jetty6-access-log4j-impl-6.1.7.jar</Arg>
</Call>
<Call class="org.mortbay.jetty.JettyServerLog4JConfig" name="setLog4JConfigPath">
<Arg><SystemProperty name="jetty.home" default="."/>/lib/log4j/log4j-jetty-config.xml</Arg>
</Call>
<Call class="org.mortbay.jetty.JettyServerLog4JConfig" name="configure"/>

Individual access loggers would still be simple to setup:

<Set name="requestLog">
<New id="RequestLogImpl" class="org.mortbay.jetty.Log4JRequestLogger" >
<Set name="accessLoggerName">TestContext</Set>
</New>
</Set>

Is this an acceptable approach to this problem?

I think the pathing has been straightened out. I'll attach a zip of the package as it sits in my contrib directory. Unit tests still need to be added, but I'd like to see if anyone has any feedback. It should drop into jetty 6.1.7 and work in its current state though. The readme has some config examples.

Chance

Here it is.

thoughts joakim since you have been neck deep in logging lately

This issue has been moved to https://bugs.eclipse.org/bugs/show_bug.cgi?id=396562.

Joakim, if this issue is still relevant, then please ensure that if the patch is to be used that it passes Eclipse IP procedures.

Jan