If I understand you correctly, then no that isn’t what I would want. The version and priority are captured in the same properties file where the class name is specified. If the class implements the wrong version or isn’t chosen due to its priority then the class isn’t loaded. To do what you are describing would require that serviceLoader load each class and that methods be called on each class to get that information. While that makes life simpler for the serviceLoader it makes it more complicated for the services being loaded.
Ralph > On Sep 30, 2015, at 12:46 AM, Peter Levart <peter.lev...@gmail.com> wrote: > > > > On 09/29/2015 11:17 PM, Ralph Goers wrote: >> FWIW, I considered using the ServiceLoader to bind the Log4j API to the >> implementation. However, Log4j also includes the API version and only looks >> for bindings that implement that version. We also include a “priority” - the >> binding with the highest priority wins - at the moment. At some future time >> we might consider supporting multiple bindings. >> >> It would have been nice if ServlceLoader could be extended by the user to do >> these sort of checks instead of not being able to use it at all. >> >> Ralph > > Hi Ralph, > > ServiceLoader can be used to load all services that implement a particular > type (it's an Iterable). So you can decide which one(s) to use in your own > logic. You just have to design the service type in a way where it's > implementations expose some attributes that are relevant for selection and > initialize the underlying service lazily, after selection is done. This would > usually mean that the service interface/abstract class implements a factory > for the real service and exposes some properties such as version, priority, > etc... > > Would that work for Log4j? > > Regards, Peter > >> >>> On Sep 29, 2015, at 11:40 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: >>> >>> On 20/09/15 15:46, Peter Levart wrote: >>>> >>>> On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote: >>>>> New JEP Candidate:http://openjdk.java.net/jeps/264 >>>>> >>>>> - Mark >>>> Hi, >>>> >>>> What is the purpose of exposing a factory for loggers in the generally >>>> exported package (java.lang) and making it standard Java API as opposed >>>> to keeping it internal API as it is now >>>> (sun.util.logging.PlatformLogger)? Is this going to become an official >>>> front-end for JDK-internal and applications use, available in the >>>> platform itself? >>> Hi Peter, >>> >>> sun.util.logging.PlatformLogger is a module private API in >>> java.base, yet it is used by other modules in the JDK - and >>> this requires qualified exports to the modules that use it. >>> Having a public API that JDK modules could use would simplify >>> the module graph in this respect. >>> >>> In time, I'd hope to see sun.util.logging.PlatformLogger disappear >>> in favor of the public API. >>> >>>> Otherwise I think it's good to add support for interfacing other >>>> backends (besides JDK14 Logging and stderr) to platform logger. If one >>>> wants to interface some other backend to platform logger now, it's >>>> actually doable, but only via the intermediate JDK14 Logging API, like >>>> this: >>>> >>>> PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND >>>> >>>> Adding support to skip JDK14 Logging would simplify configuration and >>>> make it more lightweight. >>> Yes - the goal of the LoggerFinder service API is to make it possible >>> for applications - or frameworks - to provide their own implementation. >>> >>> best regards, >>> >>> -- daniel >>> >>>> Regards, Peter >>>> >>> >> > >
