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
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:
<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]
