Hi Chris, On 1.06.2025 17:36, Christopher Schultz wrote: > This is also very helpful. It sounds like I need a filter that simply > does not pass anything (i.e. filters everything). That would cause the > SmtpAppender to hold everything together. At the end (this is a > scheduled process which starts and ends, and I want to deliver at the > end of the process), how does one indicate to the appender that it's > time to "let it all go"? I don't necessarily want to log a message like > "done!" because I don't want that actually in the output. Will the > SmtpAppender automatically send on shutdown? I am currently calling > LogManager.shutdown() at the end of the process (log4j 1.x).
No, the `SmtpAppender` does not automatically send an email when it stops. Calling `LogManager.shutdown()` does not trigger the appender to flush or send buffered log events. The `filter` element in the configuration is primarily intended for use cases where you want an `ERROR` event to trigger an email that includes some contextual lower-level log events from just before the error. Your use case—delivering all log events at the end of a scheduled process—seems quite different. What you're describing is more aligned with batch logging, where logs are buffered and sent in groups. Many database appenders[1] support this behavior via a `bufferSize` attribute that controls how many events are stored before being written. Unfortunately, `SmtpAppender` does not support this kind of batching out of the box, but it might be worth exploring whether we can add such a feature. [1] https://logging.apache.org/log4j/2.x/manual/appenders/database.html > I don't want to modify any files, here, if possible. The idea is to load > the "proper" configuration from the file as usual, but then be able to > enable or disable e.g. TRACE logging for specific loggers and/or > appenders as necessary. > > Is there any way to do this kind of thing programmatically? I can see in > the Solr Dashboard that (a) log4j2 is being used and (b) appears to > allow the user to adjust the log level for all loggers through that > interface. I haven't gone into the code to figure out how it's done, but > it leads me to believe that everything can be done ephemerally in a > running JVM without writing any files or anything like that. There is a Configurator[3] class in Log4j Core that lets you change log levels programmatically. It's the recommended approach, but it comes with two caveats: - It only works with Log4j Core, not with other Log4j API implementations. Replacing the logging backend would break this functionality. - It changes levels only for the logger context of the caller, which may not be suitable in multi-user environments. Back in November, I started working on a small API[4] that can list and modify log levels independently of the logging implementation. I haven’t made much progress since—I still need to address the question how to prevent third-party libraries modifying the logging configuration requested by the application developer (see Issue #1[5]). I initially borrowed a pattern from Tomcat's JNDI implementation, requiring a private token object to access the API. But that may be too restrictive. Long term, I want this to support use cases like preventing a Spring Boot app from adjusting global log levels in an application container. Would love your thoughts on how best to approach that. Piotr [3] https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/config/Configurator.html [4] https://github.com/apache/logging-admin [5] https://github.com/apache/logging-admin/issues/1 --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
