Jetspeed 2
  1. Jetspeed 2
  2. JS2-508

Fixing commons-logging on WebSphere and other application servers

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-dev
    • Fix Version/s: 2.1-dev, 2.1
    • Component/s: Components Core, Other
    • Labels:
      None
    • Environment:
      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

        # debug level for jetspeed specific messages
        log4j.category.org.apache.jetspeed = DEBUG, pa
        log4j.additivity.org.apache.jetspeed = false

        # 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...

        Issue Links

          Activity

          Hide
          Ate Douma added a comment -

          Closed again now properly recorded against Fix Version 2.1 as well

          Show
          Ate Douma added a comment - Closed again now properly recorded against Fix Version 2.1 as well
          Hide
          Ate Douma added a comment -

          One last remark:

          Deploying the latest Jetspeed-2 (including the new webapp-logging component) on WebSphere 5.1.* works when both the ear and web module classloaders are set to PARENT-LAST and the shared libraries are made properly made available as well
          (from the ear with proper META-INF/MANIFEST.MF Class-Path settings, from a custom shared libraries path, or the global WAS lib folder).

          But:

          • container authentication (using the JAAS LoginModules) does not work
          • the j2-admin application fails to start on WAS 5.1.* because it uses myfaces JSF which requires jsp-2.0 but that isn't supported by WAS 5.1.*
          Show
          Ate Douma added a comment - One last remark: Deploying the latest Jetspeed-2 (including the new webapp-logging component) on WebSphere 5.1.* works when both the ear and web module classloaders are set to PARENT-LAST and the shared libraries are made properly made available as well (from the ear with proper META-INF/MANIFEST.MF Class-Path settings, from a custom shared libraries path, or the global WAS lib folder). But: container authentication (using the JAAS LoginModules) does not work the j2-admin application fails to start on WAS 5.1.* because it uses myfaces JSF which requires jsp-2.0 but that isn't supported by WAS 5.1.*
          Hide
          Ate Douma added a comment -

          Implemented

          Show
          Ate Douma added a comment - Implemented
          Hide
          Ate Douma added a comment -

          One additional step to make proper use of the new jetspeed-webapp-logging component:

          • include both commons-logging and log4j in your WEB-INF/lib, or make sure they are available from the shared classpath (like on JBoss).
          Show
          Ate Douma added a comment - One additional step to make proper use of the new jetspeed-webapp-logging component: include both commons-logging and log4j in your WEB-INF/lib, or make sure they are available from the shared classpath (like on JBoss).

            People

            • Assignee:
              Ate Douma
              Reporter:
              Ate Douma
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development