[
https://issues.jboss.org/browse/LOGMGR-45?page=com.atlassian.jira.plugin....
]
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