IMO we should not do any reflection magic, you just say which module you want, nice and simple. Internally, this might mean we alias the appender names just like we did for mongodb Appenders when MongoDb 4 came out. I'm not sure what the names should be in this case. Prefixing Appender names with Jakarata or JEE/Jee is fine w me but unlikely to please others, as would renaming the old Appender to something else.
Gary Gary On Sat, Mar 5, 2022, 03:31 Piotr P. Karwasz <[email protected]> wrote: > 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 >
