[ grinder-Feature Requests-3418525 ] Switch to a standard logging framework

Feature Requests item #3418525, was opened at 2011-10-04 08:46
Message generated for change (Comment added) made by philipa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=368598&aid=3418525&group_id=18598

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core engine
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Philip Aston (philipa)
Assigned to: Philip Aston (philipa)
Summary: Switch to a standard logging framework

Initial Comment:
The Grinder should use a standard logging framework, such as java.util.Logging.

----------------------------------------------------------------------

>Comment By: Philip Aston (philipa)
Date: 2012-01-01 10:59

Message:
Implemented for next release.

I used Logback and SLF4J. 

I didn't localise the messages, this should be a separate feature request.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2011-12-27 08:18

Message:
#2633820 (which is the URL in Travis's last comment) is about the data log.
#3035781 is about the format of the data log.

This ticket concerns the standard log messages (out-*, error-*). Pluggable
data logging is tracked under #2633820.

My current thinking:
1. Remove the concept of a separate error file. Instead each worker process
will produce a single log stream, using "info" and "error" log levels
appropriately.
2. Use a separate file for each worker process.
3. Delegate the business of log file management (rolling, deleting, ..) to
the underlying framework. This may break existing downstream projects, but
they will benefit overall from the features provided by a standard
framework.
4. ScriptContext.getLogger() will return an implementation of
org.slf4j.Logger instead of the n.g.c.Logger. This will break scripts that
use the existing logging, but again they will benefit overall from the
standard framework.

Implementation thoughts:
1. SLF4J for the API.
2. CAL10N for internationalisation.
3. Logback for the logging framework.


----------------------------------------------------------------------

Comment By: Travis Bear (tbear)
Date: 2011-10-22 16:51

Message:
Including a data logger would help resolve ticket #3035781. 
(https://sourceforge.net/tracker/?func=detail&aid=2633820&group_id=18598&atid=368598)
 

I'd vote for a logger that writes to non-SQL databases as well  (bdb,
Voldemort, Cassandra, etc) .  But if this were a configurable option users
could provide their own loggers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=368598&aid=3418525&group_id=18598

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox