JEP 264: Platform Logging API and Service

[Ralph Goers]

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.levart at 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.fuchs at oracle.com> wrote:
>>> 
>>> On 20/09/15 15:46, Peter Levart wrote:
>>>> 
>>>> On 09/18/2015 06:17 PM, mark.reinhold at 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
>>>> 
>>> 
>> 
> 
>