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
        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: