Jetty
  1. Jetty
  2. JETTY-835

Add an implementation of RequestLog that supports Log4j

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Trivial Trivial
    • Resolution: Duplicate
    • Affects Version/s: 6.0.2, 7.0.0.pre5, 6.1.14, 6.1.15.pre0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      1

      Description

      Currently one implementation of RequestLog exists: NCSARequestLog
      NCSARequestLog only supports writing logs to a file on disk of the localhost

      For users that need more logging options, another implementation of RequestLog that supports Log4j (or Apache commons logging) could probably satisfy any other possible logging options desired by Jetty users.

      It could be named CommonsRequestLog, if using Apache commons logging - which also supports Log4j.
      Or it could be named Log4jRequestLog, if using only Log4j logging.

      With Log4j support for the access logs, Jetty would be able to log access logs to a syslog facility.
      In some enterprise deployments, syslog is used to centralize logs from a server farm onto a single centralized secure server.

      For further information, please see the thread:
      user@jetty.codehaus.org, "RequestLog with syslog support", 2008-12-12

        Activity

        Hide
        Ceki Gulcu added a comment -

        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

        Show
        Ceki Gulcu added a comment - 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
        Hide
        Russell E Glaue added a comment -

        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.

        Show
        Russell E Glaue added a comment - 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.
        Hide
        Ceki Gulcu added a comment -

        Hi Russell,

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

        Show
        Ceki Gulcu added a comment - Hi Russell, If you have any specific question about an logback or logback-access do not hesitate to ask on the logback user list.
        Hide
        Russell E Glaue added a comment -

        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

        Show
        Russell E Glaue added a comment - 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
        Hide
        Ceki Gulcu added a comment -

        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

        Show
        Ceki Gulcu added a comment - 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
        Hide
        Jan Bartel added a comment -

        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

        Show
        Jan Bartel added a comment - 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
        Hide
        Russell E Glaue added a comment -

        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 .

        Show
        Russell E Glaue added a comment - 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 .
        Hide
        Ceki Gulcu added a comment -

        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.

        Show
        Ceki Gulcu added a comment - 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.
        Hide
        Russell E Glaue added a comment -

        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

        Show
        Russell E Glaue added a comment - 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
        Hide
        Jesse McConnell added a comment -

        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

        Show
        Jesse McConnell added a comment - 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
        Hide
        Russell E Glaue added a comment -

        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

        Show
        Russell E Glaue added a comment - 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
        Hide
        Chance Yeoman added a comment -

        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

        Show
        Chance Yeoman added a comment - 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
        Hide
        Jesse McConnell added a comment -

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

        Show
        Jesse McConnell added a comment - jetty6 is 1.4 requirement for that component, and then jetty7 is 1.5 required
        Hide
        Chance Yeoman added a comment -

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

        Show
        Chance Yeoman added a comment - Ok. For the Jetty6 version, I'll just build the message string in the same way as the NCSARequestLog.
        Hide
        Chance Yeoman added a comment -

        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?

        Show
        Chance Yeoman added a comment - 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?
        Hide
        Chance Yeoman added a comment -

        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

        Show
        Chance Yeoman added a comment - 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
        Hide
        Chance Yeoman added a comment -

        Here it is.

        Show
        Chance Yeoman added a comment - Here it is.
        Hide
        Jesse McConnell added a comment -

        thoughts joakim since you have been neck deep in logging lately

        Show
        Jesse McConnell added a comment - thoughts joakim since you have been neck deep in logging lately
        Hide
        Jan Bartel added a comment -

        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

        Show
        Jan Bartel added a comment - 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

          People

          • Assignee:
            Joakim Erdfelt
            Reporter:
            Russell E Glaue
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: