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] Commented: (JS2-508) Fixing commons-logging on WebSphere and other application servers
Date Wed, 08 Mar 2006 16:36:39 GMT
    [ http://issues.apache.org/jira/browse/JS2-508?page=comments#action_12369491 ] 

Ate Douma commented on JS2-508:

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

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

> 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: Components Core, Other
>     Versions: 2.1-dev
>  Environment: WebSphere & 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
> 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
>   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
> 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