Issue Parsing Filter Expression for Severity Attribute in Boost Log 1.84 Configuration

[janbilek]

Encountered an issue with parsing the filter expression Filter="%Severity% > 0" in a configuration file for Boost Log (version 1.84). The logger initialization fails with the error:

Failed to parse argument value from "0"

Attempted various solutions, including:

Removing spaces around the operator (e.g., Filter=%Severity%>0). Using attr[%Severity%] to explicitly reference the severity attribute (e.g., Filter=attr[%Severity%] > 0). Escaping characters like %.

None of these approaches resolved the issue, and another error appeared: Unexpected characters in the end of the line.

From reviewing the code at filter_parser.hpp, it seems the filter parser might not be correctly handling this comparison expression or interpreting %Severity% correctly. Further investigation into how severity level filters are parsed and handled could be helpful.

We are using Boost Log version 1.84 and suspect this could be a bug or an issue with how the library parses these filters in configuration files.

Whole properties file example which used to be working while ago (can't track it back easily, sorry):

DisableLogging=false
Filter="%Severity% > 0"

[Sinks.TextFile]
Destination=TextFile
Format="[%TimeStamp%] [%Component%] <%Severity%> - %Message%"
AutoFlush=true
RotationSize=10485760
MaxSize=104857600
FileName="bp-node_%N.log"
ScanForFiles=Matching
Target=logs

[Sinks.Console]
Destination=Console
Format="[%TimeStamp%] [%Component%] <%Severity%> - %Message%"
AutoFlush=true

[Lastique]

The message Failed to parse argument value from "0" you're seeing suggests that the expression parser works correctly as it correctly extracted the argument "0" from the comparison expression. The error is generated by the operator>> for your Severity attribute value type which is called here. Check what your operator>> does and where it fails.

I cannot reproduce this locally, but I also don't have your test code. You must be registering your filter factory for the Severity attribute by calling register_simple_filter_factory or register_filter_factory.

[janbilek]

Thank you @Lastique ! After further investigation, we discovered that in Boost Log (version 1.84), the filter expression for severity no longer accepts numeric values directly. The severity attribute now expects an enumerator value instead.

To resolve the issue, we updated the filter expression from: Filter="%Severity% > 0"

To the following: Filter="%Severity% >= debug"

This change resolves the parsing error, and the logger initializes correctly with the filter applied.

Recommendation: Kindly recommend updating the Boost Log documentation to reflect this change from numeric values to enumerators in the severity filter expressions. This would help avoid confusion for developers upgrading to newer versions of the library.

[Lastique]

The interpretation of the filtering expression string depends on the attribute value type. Specifically, the format of the argument is defined by the operator>> for that type. E.g. if your Severity attribute value type is int then the argument of "0" would be accepted and if your Severity attribute value type is trivial::severity_level then its operator>> expects enumerators, and this has been the case forever.

The only relevant change I can see is 08bd1fb8090a9cff80b408ab102cc1a16ce7f1eb. But it added support for trivial::severity_level to the default filter factory. I.e. where previously the parsed filter would not recognize attribute values of type trivial::severity_level (and would always return false for conditions involving such attributes), after the change it does.