You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2006/03/08 17:28:58 UTC

[jira] Resolved: (JS2-508) Fixing commons-logging on WebSphere and other application servers

     [ http://issues.apache.org/jira/browse/JS2-508?page=all ]
     
Ate Douma resolved JS2-508:
---------------------------

    Resolution: Fixed

Implemented

> 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 5.1.1.8 & 6.0.0.1 on both Linux and Windows XP
>     Reporter: Ate Douma
>     Assignee: 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:
>     <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...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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