terracotta log4j should be configurable in a customer facing way, and should be
be friendlier with regards to integrating with existing log handling schemes
------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: CDV-529
URL: https://jira.terracotta.org/jira//browse/CDV-529
Project: Community Development
Issue Type: New Feature
Reporter: Tim Eck
Assignee: Issue Review Board
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.terracotta.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
