Uploaded image for project: 'Jetspeed 2 (Retired)'
  1. Jetspeed 2 (Retired)
  2. JS2-508

Fixing commons-logging on WebSphere and other application servers

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.1-dev
    • 2.1-dev, 2.1
    • Components Core, Other
    • None
    • WebSphere 5.1.1.8 & 6.0.0.1 on both Linux and Windows XP

    Description

      Some time ago, I created the org.apache.jetspeed.util.IsolatedLog4JLogger utility class to allow commons-logging + Log4J to be used from within
      a web application on Application Servers which provide and enforce their own Log4J setup.
      For Jetspeed, this has been configured and used since then, but the same "problem" also exists for "normal" web/portlet applications of course.
      Especially on Websphere, this turns out to be almost impossible to get working when using the recommended, and sometimes required, but
      not default PARENT-LAST classloader setting.

      Therefore, I will create a new jetspeed component, webapp-logging, containing the original IsolatedLog4JLogger and a new web application
      Context Listener class, Log4JConfigurator, which can be used by any web application (so not just portlet applications) to "fix" these annoying
      logging problems.

      Note: This will only be working if you use jakarta commons-logging together with Log4J.
      If you happen to (want to) use only Log4J, this won't help you a bit...

      To use this new component:

      • Put the jetspeed-webapp-logging-<version>.jar in your WEB-INF/lib folder
      • Modify your web.xml to include the Log4JConfigurator like this:

      <listener>

      <listener-class>org.apache.jetspeed.webapp.logging.Log4JConfigurator</listener-class>

      </listener>

      • Optionally override default configuration parameters of the Log4JConfigurator with context params in your web.xml
        (note: these have to be provided/defined before the listener(s)):

      <!-- Log4JConfigurator context-listener parameters -->
      <!--
      log4j.config.file: path to your log4j.properties file
      <context-param>
      <param-name>log4j.config.file</param-name>
      <param-value>/WEB-INF/log4j.properties</param-value>
      </context-param>
      -->
      <!-- log4j.config.webApplicationRoot.key: variable name you can use within your log4j.properties file to refer to your web application root folder.
      <context-param>
      <param-name>log4j.config.webApplicationRoot.key</param-name>
      <param-value>webApplicationRoot</param-value>
      </context-param>
      -->

      • Move your log4j.properties file to WEB-INF/log4j.properties (where its looked for by default)
        or somewhere else (and then define its location through the log4j.config.file context-param) as long as you
        don't put/keep it in WEB-INF/classes
      • Optionally make use of the ${webApplicationRoot} variable (or some other variable name as you can override with the
        log4j.config.webApplicationRoot.key context-param) to store your log files relatively from your installation directory.

      Example content for a log4j.properties:

      log4j.rootLogger = ERROR, pa

      1. debug level for jetspeed specific messages
        log4j.category.org.apache.jetspeed = DEBUG, pa
        log4j.additivity.org.apache.jetspeed = false
      1. store the logfile in a logs directory under the webapp root (make sure this directory exists!)
        log4j.appender.pa = org.apache.log4j.FileAppender
        log4j.appender.pa.file = ${webApplicationRoot}/logs/pa.log
        log4j.appender.pa.layout = org.apache.log4j.PatternLayout
        log4j.appender.pa.layout.conversionPattern = %d [%t] %-5p %c - %m%n
        log4j.appender.pa.append = false

      I will update the Jetspeed web application itself too to make use of this new component (replacing the old custom setup).
      Because the current Jetspeed configuration uses a different location (and name) for the log4j.properties, as well as
      expects the variable ${applicationRoot} to contain the Jetspeed application root folder, I'll provide overrides to the defaults
      Log4JConfigurator expects with context-params as described above.

      Very important: Do not redefine your own log4.config.webApplicationRoot.key value to "applicationRoot"!
      Jetspeed for some reason (yet unknown to me) also defines this variable as System property at runtime!
      And, because Log4J will first check for System properties when resolving variables, this means that "your" ${applicationRoot}
      variable will end up pointing at the Jetspeed web application root folder...

      Attachments

        Issue Links

          Activity

            People

              ate Ate Douma
              ate Ate Douma
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: