[logback-dev] [JIRA] Updated: (LBCLASSIC-53) Add MDC Level Filtering

[Ralph Goers]

First, I hate using "high" and "low" for logging levels. I find it 
confusing as I usually think of Debug as high since it is a greater 
verbosity, rather than a lower numeric value.

Next your description doesn't seem to describe how the filter actually 
works. I'm somewhat confused as well because in one paragraph you said 
"can easily accommodate case 2" and then in the next paragraph "the 
second case cannot be accommodated".

I have to look at the code again but I'm pretty sure it should work 
differently than what you describe. It should accomodate both use case 1 
and 2.

Assume that the default level is set to Warn. Messages destined for user 
carol would be rejected by this filter (i.e. return DENY) unless they 
are Warn or Error messages. On the other hand, if users Alice and Bob 
are set to Debug then messages that match them will pass through the 
filter unless they are trace messages. However, we don't want to accept 
these just yet as the intention is not to log everything for these 
users, only to allow the rest of normal filtering to occur. To do that 
the filter must return NEUTRAL. This allows use case 1 to work correctly.

Now, if the default level was Trace all messages would pass through the 
filter. However, if Alice and Bob are now set to Error messages related 
to them would not pass through the filter unless they were only Errors. 
This should satisfy use case 2.  To

The default level was not useful in any of the use cases you named 
because you didn't include any messages from Carol.

In my usage of the filter I expect the default level to normally be set 
to Error.

If the code doesn't work the way I described it needs to be corrected so 
it does.

Ralph


Ceki Gulcu wrote:
> Ralph,
>
> As you can see from my recent commits, I have started working on /LBCLASSIC-53. 
> It makes use of Joran's capabilities so as to shorten and improve on the 
> configuration syntax required the filer. It is a mere refactorisation of your 
> work, without any change in behavior.
>
> However, I am wonder if behavioral changes are not called for.
>
> I can think of two major use cases.
>
> The logging system is mostly silent but we would like to increase verbosity for 
> users Alice and Bob and keep it as is for the other users.
>
> The logging system is mostly verbose but we would like to decrease verbosity for 
> certain requests, say typeA and typeB, and keep it as is for the other types of 
> requests. Here I assume that the type of request is can be easily and accurately 
> set on the MDC.
>
> Now, DynamicThresholdFilter, as a threshold, can easily accommodate case 2. Set 
> the threshold to a high value for typeA and TypeB, and set the root level to a 
> low level such as DEBUG or INFO. You are done.
>
> The second case cannot be accommodated with the current implementation of 
> DynamicThresholdFilter because it returns NEUTRAL when the request level is 
> higher or equal to the threshold level (computed dynamically from MDC). We would 
> want to return ACCEPT instead. Do you see why?
>
> I also note that the defaultThresold value is not useful in any of the above use 
> cases.
>
> Would you agree thus far?
>
>
>
> Ralph Goers (JIRA) wrote:
>   
>>      [ http://jira.qos.ch/browse/LBCLASSIC-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Ralph Goers updated LBCLASSIC-53:
>> ---------------------------------
>>
>>     Attachment: MDCLevelFilter.zip
>>
>> TurboFilter that implements this feature.
>>
>>     
>>> Add MDC Level Filtering
>>> -----------------------
>>>
>>>                 Key: LBCLASSIC-53
>>>                 URL: http://jira.qos.ch/browse/LBCLASSIC-53
>>>             Project: logback-classic
>>>          Issue Type: New Feature
>>>         Environment: All
>>>            Reporter: Ralph Goers
>>>            Assignee: Logback dev list
>>>         Attachments: MDCLevelFilter.zip
>>>
>>>
>>> The company I work for is an Application Service Provider. Requests to the same software running in a single JVM might be on behalf of any one of these companies. In addition, our middle tier contains services that my be called from several different products and are run on behalf of a user of one of these companies. Operationally, we require the ability to be able to filter based on company, product, possibly the end user or several other criteria.
>>> The TurboFilter provided allows individual values for keys in the MDC to be associated with a logging level.  So if the MDC contains a key for the company the TurboFilter can be configured with the name of the company and the corresponding logging level. So if CompanyA's level is set to debug while the default level is error, only debug events for CompanyA will be passed on.
>>>       
>
>