Default property values for syslog logging

[kanwhoa]

Describe the bug

The default values for syslog logging cause log messages not to be accepted. This was tested when using Keycloak. The original issue was raised with Keycloak and redirected here.

The issue comes down the quarkus.log.syslog.use-counting-framing flag. When the quarkus.log.syslog.protocol parameter is set to tcp or ssl-tcp, RFC5424 states that byte counting framing should be used. For Quarkus, this means also manually setting the quarkus.log.syslog.use-counting-framing flag (which Keycloak does not have a proxy option for).

When sending logs to a receiver such as syslog-ng without the flag, these log messages are rejected with an 'invalid framing' error and the connection is dropped.

Expected behavior

The request here is to automatically set quarkus.log.syslog.use-counting-framing to true if the quarkus.log.syslog.protocol parameter is set to tcp or ssl-tcp. It should be possible to override this manually in case there are specific edge cases not following RFC5424.

Actual behavior

Presently, when using syslog logging, the quarkus.log.syslog.use-counting-framing must be manually set. In Keycloak, this is performed by setting the quarkus.properties. This is something that is recommended against in the documentation

How to Reproduce?

1. Setup a syslog receiver (see example on the Keycloak issue).
2. Set the approvriate log flags

• quarkus.log.syslog.enable=true
• quarkus.log.syslog.endpoint=localhost:514
• quarkus.log.syslog.app-name=example
• quarkus.log.syslog.facility= local-use-0
• quarkus.log.syslog.syslog-type=rfc5424
• quarkus.log.syslog.protocol=tcp

3. Create logging events

Output of uname -a or ver

Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:46 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T8112

Output of java -version

openjdk version "21.0.7" 2025-04-15 OpenJDK Runtime Environment Homebrew (build 21.0.7) OpenJDK 64-Bit Server VM Homebrew (build 21.0.7, mixed mode, sharing)

Quarkus version or git rev

From Keycloak 26.2.4 (Quarkus 3.20.0)

Build tool (ie. output of mvnw --version or gradlew --version)

N/A

Additional information

No response

[quarkus-bot]

/cc @dmlloyd (logging)

[geoand]

@dmlloyd @jamezp WDYT?

[dmlloyd]

Seems reasonable. We could solve this in one of two possible ways:

• A dynamic default configuration source which sets the default to true or false depending on the selected protocol
• Change the property to a enum with values TRUE, FALSE, PROTOCOL_DEPENDENT

The most correct answer would be to research the RFCs and prevent invalid configurations instead of exposing every knob (an anti-pattern which leads directly to user confusion and, ironically, inflexibility). But that ship has sailed in this case.

It might be tempting to make this property be an Optional<Boolean>. This would be an error.

[jamezp]

A little OT, but I wonder if we should deprecate RFC-3164 as it's been obsolete for over 14 years now :)