TurboFilters should be called with format/params/throwable when using fluent logging API

[christophejan]

I think TurboFilter decide method should be called with provided format/params/throwable the same way whether fluent logging API has been used or not.

Currently, with slf4j-api 2.0.16 and logback-classic 1.5.8 :

• logger.info(“Hello world.”); call TurboFilter decide method with provided format/params/throwable
• logger.atInfo().log(“Hello world.”); never call TurboFilter decide with provided format/params/throwable (A call equivalent to logger.isInfoEnabled() with null format/params/throwable is done ; that’s not a problem but that’s not what is expected).

In logback documentation, I found :

• On Fluent Logging API : The statement logger.atInfo().log(“Hello world.”); is equivalent to : logger.info(“Hello world.”);
• […] (TurboFilter) are called not only when a given appender is used, but each and every time a logging request is issued. Their scope is wider than appender-attached filters.

I think it’s an issue that TurboFilters is not called with format/params/throwable when using fluent logging API.

[jakobleck]

+1
I had an issue trying to filter logs using a TurboFilter based on matching the format with a specific string and returning a DENY, but in the resulting logs in the console the string still appeared, presumably from calls to decide with format = null. Adding a

    if (format == null) {
      return FilterReply.DENY;
    }

to the decide fixed it, but doesn't look that good to me... (Or is it?)

At the very least, I think, it should be documented that TurboFilter's decide can be called with null parameters.

[christophejan]

Hi @jakobleck

Denying all decide calls with null format will skip all code blocks inside any isXxxEnabled. You may filter out a lot of logs you don’t want to miss.

This issue is only regarding logs emitted with fluent api that never call decide with provided format (etc.).

[christophejan]

Hi @ceki,

Sorry to bother you. Could you please give us some guidance. Do you agree that current behavior is an issue ? Do you plan to continue to maintain and enhance Turbo filter (like adding KeyValuePairs as parameter) or do do you recommend to rather switch to regular filter ? Regular filter will be much less easy to use in some use case as regular filter are not tied to the logging context but at appender level. Anyway, it could be better than staying on a feature you perhaps consider legacy.

Thanks a lot for this great lib.

Regards