So far I've figured out that you can specify multiple classes in a ServiceLoader file. Each line can have a class. And the order things are parsed are determined by ClassLoader.getResources() (which I'd assume is classpath order). This could really use a sort of extension that allowed prioritizing services.
On 7 October 2014 21:21, Matt Sicker <[email protected]> wrote: > It's actually a bit more complicated than I thought. Sometimes, the > properties are there for overriding the default (usually with another > log4j-provided class instead of a custom one). I'll have to delve into this > a bit more. > > On 7 October 2014 21:18, Matt Sicker <[email protected]> wrote: > >> Let me compile a list of example service classes that could benefit from >> using ServiceLoader. I'll be back soon. >> >> On 7 October 2014 21:11, Ralph Goers <[email protected]> wrote: >> >>> 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]> >>> >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> > > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
