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] Resolved: (JS2-543) Velocity logging using the jetspeed-webapp-logging component
Date Fri, 09 Jun 2006 12:54:30 GMT
     [ http://issues.apache.org/jira/browse/JS2-543?page=all ]
Ate Douma resolved JS2-543:

    Resolution: Fixed

> Velocity logging using the jetspeed-webapp-logging component
> ------------------------------------------------------------
>          Key: JS2-543
>          URL: http://issues.apache.org/jira/browse/JS2-543
>      Project: Jetspeed 2
>         Type: Improvement

>   Components: Admin Portlets, Demo Portlets, Assembly/Configuration, Ajax
>     Versions: 2.1-dev
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>     Priority: Minor
>      Fix For: 2.1, 2.1-dev

> By default, Velocity can already log message using Log4J if properly setup, but not through
Commons Logging.
> For the Jetspeed portal application, most (!) Velocity logging is already properly handled
because the JetspeedVelocityServlet uses its own Velocity LogSystem implementation
> which uses a Commons Logging Log instance.
> But other VelocityEngines used from within Jetspeed (like the ones used for AJAX), as
well as the engines used by the j2-admin, demo and rss web applications don't have
> this properly handled yet, with as result that all their logging information is current
> The jetspeed-webapp-logging component provides a generic solution for properly logging
from within a web application using *both* Commons Logging and Log4J.
> See: JS2-508 - Fixing commons-logging on WebSphere and other application servers.
> But, the jetspeed-webapp-logging solution requires that all logging is routed through
Commons Logging and not directly through Log4J itself.
> So, I'm going to provide a custom Velocity LogSystem implementation, org.apache.jetspeed.webapp.logging.velocity.CommonsLoggingLog4JLogSystem,
as part of the
> jetspeed-webapp-logging component.
> This CommonsLoggingLog4JLogSystem can be configured in velocity.properties file as follows:
>     # use Commons Logging for routing Velocity message through our IsolatedLog4JLogger
>     runtime.log.logsystem.class =org.apache.jetspeed.webapp.logging.velocity.CommonsLoggingLog4JLogSystem
>     # Log4J Category used (default is "velocity")
>     runtime.log.logsystem.log4j.category = velocity
> This is a standard solution provided by Velocity, for more information check: http://jakarta.apache.org/velocity/docs/developer-guide.html
> The configured log4j.category maps of course on a category defined in the log4j.properties,
and has as default value "velocity".
> Note: some VelocityEngines used by Jetspeed are created through Spring with its org.springframework.ui.velocity.VelocityEngineFactoryBean.
> By default Spring will override a custom logging configuration provided through a velocity.properties
(or defined inline) with their own CommonsLoggingLogSystem
> implementation. 
> That works fine too, but it uses a hard coded category based on the VelocityEngine class
name, causing the logging (in the case of the Jetspeed portal)
> to be written to the root logger (jetspeed.log). 
> So, I'm gonna override this default Spring "logging override" by setting the "overrideLogging"
property to false as I prefer all Velocity logging to be captured in our velocity.log file.
> Finally, as this solution is more generic, I'm gonna remove the custom JetspeedVelocityViewServlet
logging handling and make use of the new CommonsLoggingLog4JLogSystem instead.   
> Beware: after implementing this, I noticed *lots* of new Velocity error and warning messages
logged which were "hidden" before ;) 

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