Hi Ralph, On Sat, Mar 5, 2022 at 6:16 PM Ralph Goers <[email protected]> wrote: > In core, so long as the SmtpAppender has to remain in core then it needs to > determine if the Jakarta support is present or not and use it if it is. But I > would > suggest it do that using ServiceLoader instead of reflection. If the Jakarta > version > is present it should be given preference over the default version.
That is a very nice idea. I'll rewrite the PR to use a ServiceLoader, so that the manager factory will be chosen by the first match in the list: 1. The value of the Log4j system property "org.apache.logging.log4j.core.net.MailManagerFactory" (an interface that all SMTP manager factories will implement), 2. A service implementing the same interface, 3. The default "org.apache.logging.log4j.core.net.SmtpManager.SMTPManagerFactory". A nice thing to have would be an equivalent of JAXB's `ServiceLoaderUtil`: https://github.com/eclipse-ee4j/jaxb-api/blob/master/api/src/main/java/jakarta/xml/bind/ServiceLoaderUtil.java (actually this is copy/pasted in many Java EE artifacts). This way we can also deal with the OSGI case by delegating to the `osgi-resource-locator`. The `ServiceLoader` mechanism can actually be applied to other non Java EE appenders: e.g. in the current version the `HttpAppender` is hardcoded to use a `HttpManager` based on the `HttpURLConnection`. Piotr
