[JIRA] Created: (LBCLASSIC-190) Allow programmatic traversal of the logger tree
Allow programmatic traversal of the logger tree ----------------------------------------------- Key: LBCLASSIC-190 URL: http://jira.qos.ch/browse/LBCLASSIC-190 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.19 Reporter: Robert Elliot Assignee: Logback dev list I'm interested in writing a module for logback to allow on the fly changes to the logger tree - changing levels, adding appenders, maybe adding filters with code supplied dynamically. My vision for the gui is to show the logger tree like a folder tree. However, now I come to look at it it seems neither the child loggers nor the parent logger of a logger are exposed, which rather blows this whole concept out of the water. Is there a particularly strong reason for this? If not, I've forked logback here: http://github.com/Mahoney/logback and exposed the data. As part of the same thing I changed the children from a List to a Set as it seems more semantically correct and cleans up the code slightly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-190?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-190: -------------------------------------- List in this case works well because most operations are about iterating on all children where List is a little more convenient than a Set. A list also uses up less memory space than a Set. However, exposing a copy of the children list is possible. You would probably also be interested in a listener attached to the logger context informing you of changes made to various loggers (level change, appender add/delete).
Allow programmatic traversal of the logger tree -----------------------------------------------
Key: LBCLASSIC-190 URL: http://jira.qos.ch/browse/LBCLASSIC-190 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.19 Reporter: Robert Elliot Assignee: Logback dev list
I'm interested in writing a module for logback to allow on the fly changes to the logger tree - changing levels, adding appenders, maybe adding filters with code supplied dynamically. My vision for the gui is to show the logger tree like a folder tree. However, now I come to look at it it seems neither the child loggers nor the parent logger of a logger are exposed, which rather blows this whole concept out of the water. Is there a particularly strong reason for this? If not, I've forked logback here: http://github.com/Mahoney/logback and exposed the data. As part of the same thing I changed the children from a List to a Set as it seems more semantically correct and cleans up the code slightly.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-190?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu edited comment on LBCLASSIC-190 at 3/2/10 10:30 AM: --------------------------------------------------------------- List in this case works well because most operations are about iterating on *all* children so a Set does not grant an advantage over List. A List also uses up less memory space than a Set. So, keeping the List as is seems reasonable. However, exposing a copy of the children list is possible. You would probably also be interested in a listener attached to the logger context informing of changes made to various loggers (level change, appender add/delete). was (Author: noreply.ceki@qos.ch): List in this case works well because most operations are about iterating on all children where List is a little more convenient than a Set. A list also uses up less memory space than a Set. However, exposing a copy of the children list is possible. You would probably also be interested in a listener attached to the logger context informing you of changes made to various loggers (level change, appender add/delete).
Allow programmatic traversal of the logger tree -----------------------------------------------
Key: LBCLASSIC-190 URL: http://jira.qos.ch/browse/LBCLASSIC-190 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.19 Reporter: Robert Elliot Assignee: Logback dev list
I'm interested in writing a module for logback to allow on the fly changes to the logger tree - changing levels, adding appenders, maybe adding filters with code supplied dynamically. My vision for the gui is to show the logger tree like a folder tree. However, now I come to look at it it seems neither the child loggers nor the parent logger of a logger are exposed, which rather blows this whole concept out of the water. Is there a particularly strong reason for this? If not, I've forked logback here: http://github.com/Mahoney/logback and exposed the data. As part of the same thing I changed the children from a List to a Set as it seems more semantically correct and cleans up the code slightly.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCLASSIC-190?page=com.atlassian.jira.plugin.syste... ] Robert Elliot commented on LBCLASSIC-190: ----------------------------------------- Yes, that would be useful. I'm not yet at the point of writing code so it's not exactly holding me up; needing the listeners would probably be some way away. I thought I'd ask about the parent and children on the basis that it would be trivial to do if it was a reasonable request, and it would be useful to know now if there was a good reason why that data was not currently exposed. Thanks for the reply.
Allow programmatic traversal of the logger tree -----------------------------------------------
Key: LBCLASSIC-190 URL: http://jira.qos.ch/browse/LBCLASSIC-190 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.19 Reporter: Robert Elliot Assignee: Logback dev list
I'm interested in writing a module for logback to allow on the fly changes to the logger tree - changing levels, adding appenders, maybe adding filters with code supplied dynamically. My vision for the gui is to show the logger tree like a folder tree. However, now I come to look at it it seems neither the child loggers nor the parent logger of a logger are exposed, which rather blows this whole concept out of the water. Is there a particularly strong reason for this? If not, I've forked logback here: http://github.com/Mahoney/logback and exposed the data. As part of the same thing I changed the children from a List to a Set as it seems more semantically correct and cleans up the code slightly.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (2)
-
Ceki Gulcu (JIRA) -
Robert Elliot (JIRA)