Are we getting side tracked here? Is this all required for 2.1. We got up to RC3 this weekend. It seems we should go to RC4 and then continue on 2.2-SNAP.
Gary On Tue, Oct 7, 2014 at 10:32 PM, Matt Sicker <[email protected]> wrote: > 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]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
