Of course I'm getting side tracked, it's what I do! On 7 October 2014 22:47, Remko Popma <[email protected]> wrote:
> +1 I would also like to release what we have now. > > Sent from my iPhone > > On 2014/10/08, at 11:43, Gary Gregory <[email protected]> wrote: > > 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 > > -- Matt Sicker <[email protected]>
