portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Created: (JS2-508) Fixing commons-logging on WebSphere and other application servers
Date Wed, 08 Mar 2006 15:42:39 GMT
Fixing commons-logging on WebSphere and other application servers 

         Key: JS2-508
         URL: http://issues.apache.org/jira/browse/JS2-508
     Project: Jetspeed 2
        Type: Improvement
  Components: Other, Components Core  
    Versions: 2.1-dev    
 Environment: WebSphere & on both Linux and Windows XP
    Reporter: Ate Douma
 Assigned to: Ate Douma 
     Fix For: 2.1-dev

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:




- 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
    <!-- log4j.config.webApplicationRoot.key: variable name you can use within your log4j.properties
file to refer to your web application root folder.

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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message