[jboss-jira] [JBoss JIRA] (LOGMGR-45) Have loggers inherit filters

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/LOGMGR-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700556#comment-12700556 ] 

David Lloyd commented on LOGMGR-45:
-----------------------------------

This introduces an inconsistency with how Java's internal logging functions.  Log4j does not appear to have any equivalent either way.

That said, I don't think this is necessarily an unreasonable request.  But it will require some research to discover how to implement this in a non-performance-inhibiting fashion (levels are inherited using a tree traversal algorithm; we would probably need something similar for filters, though it's trickier because levels are not additive like filters can be).
                
> Have loggers inherit filters
> ----------------------------
>
>                 Key: LOGMGR-45
>                 URL: https://issues.jboss.org/browse/LOGMGR-45
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Kelly Dolan
>            Assignee: David Lloyd
>
> I had the need to log a specific INFO message and only that message.  This message was logged from a class whose category is org.jboss.as.server.  To get the message to even ask itself to be logged, I had to add the following to the log configuration (my STATUS handler was a simple console-handler).  Given this, I saw a lot of INFO+ messages for the org.jboss.as.server category as well as other subcategories (e.g., org.jboss.as.server.deployment).
> <logger category="org.jboss.as.server">
>   <level name="INFO"/>
>   <handlers>
>     <handler name="STATUS"/>
>   </handlers>
> </logger>
> Next, I tried to restrict it by adding the <filter> element to the <logger>.  
> <filter>
>   <match pattern="JBAS018559"/>
> </filter>
> This did not appear to work...it made no impact on what was logged.  So I moved it to the <console-handler> which only logged what I wanted it to log.
> In the forum post, it was determined the <filter> on the <logger> is not inherited.  As a result, the <filter> is only applied to the specified category, not any of its subcategories.
> This request is to change the <logger> such that its <filter> is applied to all categories it applies itself to.  From my point of view (and I realize it may be a limited view at this time), this keeps it consistent (e.g., <level> applies to all categories, <handler> applies to all categories).  W/ no documentation on this feature, inheritance was assumed.
> Also, given it currently does not apply to all categories, does it make log configurations more complicated?  In my case, I was able to easily move it to my handler but no one else was referencing it.  If it had been in use by someone else, would I have had to create a new handler to be referenced only by the logger?  Or would the filter have been able to be written in more complexity to allow logging of all it currently logs + one message - everything the new logger lets pass through?  Or could one create additional loggers for sub-categories to set level=ERROR? (All rhetorical questions.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira