:-) Sent from my iPhone
> On 2014/10/08, at 13:00, Matt Sicker <[email protected]> wrote: > > 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 >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory > > > > -- > Matt Sicker <[email protected]>
