That ServiceLoaderUtil idea could be relevant to my open DI PR where I refactored some related things to that.
— Matt Sicker > On Mar 6, 2022, at 04:10, Piotr P. Karwasz <[email protected]> wrote: > > 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
