Hello, A month ago Andy Wilkinson (from Spring Boot I presume) raised the issue of the lack of support in Log4j 2.x for the Jakarta version of Java Mail (LOG4J2-3362).
In Log4j 3.x adding such a feature is trivial (copy 'log4j-smtp` artifact, run Tomcat's conversion tool and update the dependencies), but I am not sure if Log4j 3.x will be released in time for Spring Boot 3.x (which has a baseline of Jakarta EE 9). In Log4j 2.x both the SMTP and JMS appenders are in `log4j-core`, which complicates the situation. A month ago I submitted: https://github.com/apache/logging-log4j2/pull/745 which was unacceptable, because it added the Jakarta SMTP manager directly to `log4j-core` and added new dependencies. Thanks to your objections I refurbished it with these assumptions: * the Java EE SMTP appender and manager stay in `log4j-core`, * a new 'log4j-jakarta-smtp` artifact is introduced, which only contains the manager part of the Jakarta EE SMTP appender, so that users can still use the "SMTP" plugin name in their configuration, * everything is glued together using reflection: if the SMTP appender (in `log4j-core`) detects the presence of `log4j-jakarta-smtp` it switches to the Jakarta manager. There is of course also a manual on/off switch. Can someone have a look at the PR, whether it is acceptable? With Java Mail there is also the problem of which dependencies to declare: there is a separate artifact for the Java Mail API, but the `com.sun.mail` implementation artifacts include the API classes. There are no API-less artifacts as in the case of JAXB (the `org.glassfish` artifacts). Therefore I reconfigured the dependencies of `log4j-core` to include: * the Java Activation and Mail APIs as optional compile dependencies (should it be 'provided'?), * the implementation 'java.mail' artifact as runtime dependency. Does it seem Ok? We could also create a separate `log4j-smtp` artifact of type POM, which would pull those dependencies without the "optional" part. Just to prepare users for Log4j 3.x. Piotr
