DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15450>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15450 Ability to set levels for loggers Summary: Ability to set levels for loggers Product: Commons Version: 1.0 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Something I missed when I converted from Log4J to jakarta-logging was the ability to set levels for my loggers dynamically. Part of Tapestry is the Inspector, a component/mini-application that embeds into an application. It used to have a form that listed all Log4J categories (now called "Loggers") and you could set the Priority (now "Level") for each (as well as create new loggers on the fly). I had to strip that functionality out which is unhappy, since it was very useful for enabling debug output just as you need it. Anyway, extending the LogFactory or Log interfaces with a) Method for obtaining sorted list of levels, as strings b) Method for querying level for Log c) Method for updating level for log Would be cool and useful. I would suggest that the levels exposed to the user code be strings, with an internal translation to appropriate object types. null for no-explicit level (logger inherits from parent). What's very important is the sort order, when the list of possible settings is provided. I suggest a sort order of least-to-most, i.e., "NEVER", "FATAL", "ERROR", "WARN", "INFO", "DEBUG", "ALL" would map to Log4J's default list. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
