[ http://issues.apache.org/jira/browse/JS2-508?page=comments#action_12369488 ]
Ate Douma commented on JS2-508: ------------------------------- 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). > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
