Bug 1130150 - In some scenarios filter-spec defined on logger is not inherited by handlers
Summary: In some scenarios filter-spec defined on logger is not inherited by handlers
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Logging
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: James Perkins
QA Contact: Nikoleta Hlavickova
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-14 12:43 UTC by Nikoleta Hlavickova
Modified: 2014-08-29 15:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-29 15:00:43 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1040961 None None None Never

Internal Links: 1040961

Description Nikoleta Hlavickova 2014-08-14 12:43:05 UTC
Description of problem:
When trying to filter out messages using write-attribute(name=filter-spec,value=not(match("some pattern"))) on a logger, it works for some cases but not for all. According to https://bugzilla.redhat.com/show_bug.cgi?id=1040961#c1 it should NOT work (but then it is not consistent with documentation and cli which allows this configuration).

Message I want to filter out (an example):
12:30:48,303 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 48) HHH000389: Unsuccessful: drop sequence hibernate_sequence

If I define a logger org.hibernate, the filter is not inherited by the handlers. If I define a logger org.hibernate.tool.hbm2ddl.SchemaExport, the filter is inherited by all handlers. 

Changing for example attribute "level" works also for org.hibernate -- changing it to "FATAL" means that the example message is not in the log (as expected).

Version-Release number of selected component (if applicable):
EAP 6.3.0.GA

How reproducible:
always

Steps to Reproduce:
1.1. /subsystem=logging/logger=org.hibernate:add(level=INFO)
1.2. /subsystem=logging/logger=org.hibernate:write-attribute(name=filter-spec,value=not(match("HHH000389")))

2.1 /subsystem=logging/logger=org.hibernate.tool.hbm2ddl.SchemaExport:add(level=INFO)
2.2 /subsystem=logging/logger=org.hibernate.tool.hbm2ddl.SchemaExport:write-attribute(name=filter-spec,value=not(match("HHH000389")))

Actual results:
After step 1 the message is present in the logs
After step 2 the message is not present in the logs

Expected results:
Either both 1 and 2 work and message is not present in the logs OR neither 1 nor 2 work and the message is present in the logs.

Additional info:
Either way, the functionality must be properly documented so customers know, what is the expected behaviour. Currently there is a note: A filter-spec specified for the root logger is not inherited by other handlers. The note is only in section about root logger and does not say it can work for some scenarios.

Comment 1 James Perkins 2014-08-14 15:04:53 UTC
A filter on a logger is never "inherited" by any handler. You can put a filter on a logger OR a handler. The logger filter takes precedence over the filter on a handler.

Logger handlers are not inherited. As you see above if you place a filter on org.hibernate but the logger is created with the name org.hibernate.tool.hbm2ddl.SchemaExport then the filter will not be checked. If however you place the filter on org.hibernate.tool.hbm2ddl.SchemaExport the filter will be checked on the logger.

The flow works something like this.

if (logger.isLoggable(level)) {
    if (loggerFilter.isLoggable(logRecord)) {
        publishToHandler(logRecord)
    }
}

Then in the handler:

if (handler.isLoggable(level)) {
    if (handlerFilter.isLoggable(logRecord)) {
        // write record
    }
}

In short the behavior you're seeing is expected behavior. As the previous BZ's indicate we are considering allowing filters to the inherited on loggers. At this point it's best to put filters on handlers if you don't know the specific logger name (category).


Note You need to log in before you can comment on or make changes to this bug.