CDV ❯ terracotta log4j should be configurable in a customer facing way, and should be be friendlier with regards to integrating with existing log handling schemes
-
New Feature
-
Status: Open
-
2 Major
-
Resolution:
-
-
-
prodmgmt
-
Reporter: teck
-
November 30, 2007
-
9
-
Watchers: 9
-
March 19, 2010
-
Attachments
Description
This originates from the forums: http://forums.terracotta.org/forums/posts/list/624.page
In general I think the following set of changes would go a long to improving this here: 1) Externalize as much of our logging setup (ie. default levels, appenders, etc) as possible – that is remove the hard coded stuff in TCLogging and use a properties file instead 2) Remove the .tc.dev.log4j.properties scheme, and replace it with a something designed with users in mind, not just TC developers. 3) Allow end-user appenders to be loaded. This might imply someplace where the jars can be found,. Or if we can influence which loader log4j uses to load appenders, then maybe user appenders could always be loaded with the system loader.
This one isn’t as clear to me, but we could detect if log4j is available on CLASSPATH and interact with that instance instead of the one in our lib directory. I’m a little less certain about this because of the possibility of version mismatch problems, logger name space collisions, and it opens a can of worms about bridging our logging to all of the various logging flavors out there.
Comments
peter royal 2008-10-10
Gary Keim 2009-03-21
You can redirect all TC output to stdout: or stderr: in the server and client
Sergio Bossa 2010-02-04
Tim,
I’m attaching a modified TCLogging class which will let users configure logging in a friendlier way. More specifically, it works by trying to load the .tc.custom.log4j.properties configuration file: all appenders and log definitions you apply to such a file will only affect the logs going out through the defined appender(s), with the exception of the log level which will affect also standard terracotta file logs.
For example, the following configuration snippet:
log4j.appender.myappender=org.apache.log4j.ConsoleAppender log4j.appender.myappender.Target=System.out log4j.appender.myappender.layout=org.apache.log4j.PatternLayout log4j.appender.myappender.layout.ConversionPattern= CONSOLE-%m log4j.logger.com.terracottatech.console=INFO, myappender
Will affect myappender logs and com.terracottatech.console level for both myappender and file logs. That is, console will always print CONSOLE-message, while file logs will work as always.
Sorry for not attaching a diff file, but I’ve made a code reformat, so a diff would have been useless.
Let me know what you think.
ilevy 2010-02-04
We should also get some documentation for this class and the properties file.
another vote for making logging configurable.
i prefer daemontools and multilog to manage logging in a centralized way, and not being able to redirect all TC output to stdout messes with that.