On Mon, Feb 1, 2010 at 9:16 PM, Tim Eck <t...@terracottatech.com> wrote:
> That is the class. Basically I think the change that would be nice to have > would be to externalize as much of the underlying log4j configuration as > possible (such that it can customized to taste). I think that externalizing (almost) all of the the underlying log4j configuration may open a real can of worms, mainly because: - Logging configuration is spread in TCLogging itself (hardcoded) *and* in terracotta configuration files (being able to specify log directories): I have no clue about what may happen if I make deep changes in TCLogging and I don't have too much time to investigate. - TCLogging has several public static methods with no documentation, and they could be called anywhere: I couldn't change them without solid knowledge of all things around. Technical reasons apart, I think that file-based logging should not be changed: it's very low-level and vital for basic debugging, users should not have a way to change that. Console-based logging should definitely be configurable instead: users should be able to configure at least level and layout. So I'm changing the TCLogging class to: - Try to load a custom log4j file for configuring console logging (avoiding duplicated logs and alike). - Normally log with default (hardcoded) settings if such a file couldn't be loaded. I already have a working prototype for this fix. What do you think? Cheers! Sergio B. -- Sergio Bossa Software Passionate and Open Source Enthusiast. URL: http://www.linkedin.com/in/sergiob _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
