Potential ETA on a newer Log4j release

[Pariksit-Dogra]

Hi Log4j Team, Hope you are doing well. I was curious if there is a release calendar in place or potential timeline for the next log4j-core release as I am particularly interest in the merged fix for this issue: 3947. Thank you for your hard work and happy holidays!

[vy]

I will cut 2.25.3 in a week or two.

[Pariksit-Dogra]

Thank you so much! You are a lifesaver 😭

[ppkarwasz]

Hi @Pariksit-Dogra,

In the meantime, could you try your configuration against the current 2.26.0-SNAPSHOT to confirm there aren’t any other easy fixes we should address alongside this one (e.g. problems with some characters in the ThreadContext)? You can find the snapshots repository URL on our download page.

RFC 5424 layout usage is relatively uncommon (many users unfortunately prefer the unstructured PatternLayout 😢 ), and RFC 5424 servers are designed to be fix minor formatting issues. Still, if there are some formatting problems, we'd better fix them in Log4j.

[Pariksit-Dogra]

Hi @ppkarwasz

Sorry I missed this message. I wasn't able to test against the snapshot but was able to bump up to 2.25.3. Unfortunately, I am still facing issues. Essentially, I am trying to test the sending of log messages using Syslog over TLS protocol. My tests work completely fine with TCP but break for a number of reasons (since we've upgraded from JDK17 -> 21). The trust store is being set programmatically along with the 'SSL' protocol. However, I encounter issues whereby you get NPE's for it being unable to initialise the SSL Configuration required:

@coroutine#3 ERROR Could not create plugin of type class org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog: java.lang.NullPointerException: Cannot invoke "org.apache.logging.log4j.core.net.ssl.SslConfiguration.getKeyStoreConfig()" because "sslConfig" is null
java.lang.NullPointerException: Cannot invoke "org.apache.logging.log4j.core.net.ssl.SslConfiguration.getKeyStoreConfig()" because "sslConfig" is null

With an SSL block it 'seems' to work, but that hasn't been required before and as per the log4j docs should still not be required as long as the system variables for the trustStore etc are being set before any appenders are created. As per the code that should be the case. I am not sure if this is a bug or if I'm doing something massively wrong but I've tried a lot of things already. I am happy to raise a bug issue if that would be a better place to discuss this issue further. Thank you 🙇

[vy]

@Pariksit-Dogra, would you mind submitting an issue and sharing the minimal configuration to reproduce this failure, along with the full stack trace, please? I want to ensure your issue has nothing to do with #4022.

[Pariksit-Dogra]

Thank you :) I've gone ahead and submitted an issue, tried my best to provide a reproduceable test Thank you!