Yes, I looked at it and purposely decided not to use it for the LoggerContextFactory. I wanted to do API version checking to make sure what we were binding with is compatible.
As for using it for other stuff, I am not really sure how or why ServiceLoader was bypassed. Ralph On Oct 7, 2014, at 6:49 PM, Matt Sicker <[email protected]> wrote: > This was added back in 1.6, and I still don't see it used very often. It > seems like a more effective method of making customizable service classes > than all system properties all the time (even though you can technically just > make a log4j2.component.properties file to set them). I think we could use it > for simple plugins that aren't log4j-core plugins (or even in log4j-core), or > we could make a sort of replacement class that's similar. > > If you don't already know how ServiceLoader<S> works, it looks for > META-INF/services/the.full.class.name files which contain a FQCN of the > implementation class. I'm not particularly sure about the order in which > things are loaded, but it's certainly useful when you combine it with > something like the @Order annotation we have and then sort them based on that. > > I know why we didn't use it for LoggerContextFactory what with the additional > properties to be specified for a provider. However, I don't see why we > haven't used it for other service classes. > > -- > Matt Sicker <[email protected]>
