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/06/09 14:21:31 UTC

[jira] Created: (JS2-543) Velocity logging using the jetspeed-webapp-logging component

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
 Assigned to: 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 lost!

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


[jira] Resolved: (JS2-543) Velocity logging using the jetspeed-webapp-logging component

Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
     [ 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 lost!
> 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:
   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