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
