I've been using the SLF4J API in some of my work and one thing about it that
makes it very awkward, from a dependency mangement standpoint, is that one
of the core APIs - the LoggerFactory - is actually not a part of the
slf4j-api package. Instead, its actually reimplemented in each of the slf4j
i
Eric,
Many thanks for your contribution. Given that you've gone to the trouble of
providing an implementation, I'll attempt to solve this problem without
using class loader tricks by moving LoggerFactory into slf4j-api and make
it compile by using a "bootstrap" project. I'll let you know how i
Hello,
Eric Crahen wrote:
> I've been using the SLF4J API in some of my work and one thing about
> it that makes it very awkward, from a dependency mangement standpoint,
> is that one of the core APIs - the LoggerFactory - is actually not a
> part of the slf4j-api package. Instead, its actually
Please read the Service API docs.
http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
The benefit over the current mechanism is that you have a type safe plugin
implementation & a clean separation between interface and implementation.
Today, including the LoggerFactory in each imp
Hi,
Eric Crahen wrote:
>
> I think that we can resolve the undesirable issues while still
> retaining the behavior we have today. Here is my proposal:
>
> Create a single LoggerFactory and placed it into slf4j-api, and
> deleted the LoggerFactory classes everywhere else they exist
> (slf4j
The Service API is in all sun JVMs since 1.3 under sun.misc.Service.
The docs can be found under the previous links I've sent.
On 2/15/07, Boris Unckel <[EMAIL PROTECTED]> wrote:
Hi,
Eric Crahen wrote:
>
> I think that we can resolve the undesirable issues while still
> retaining the beha
Hi Eric,
now the mails occur in wrong order, thanks for the link, in my other
mail I tried to find something about it.
Answers below.
Eric Crahen wrote:
Please read the Service API docs.
http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html
I got your mail just while sending my
Hello,
Eric Crahen wrote:
> Create a single LoggerFactory and placed it into slf4j-api, and
> deleted the LoggerFactory classes everywhere else they exist
> (slf4j-simple, logback, etc). This new LoggerFactory leverages Sun's
> ServiceProvider API which exists in all JDK's since 1.4 (maybe 1.3)
On 2/15/07, Boris Unckel <[EMAIL PROTECTED]> wrote:
just one thing:
Could you explain what happens if two or more classes/jars provide the
service?
If more than one class/jar provides the service, which one is taken?
Which one has to be taken by the factory?
The Service API allows you to enum
On 2/15/07, Boris Unckel <[EMAIL PROTECTED]> wrote:
This is especially valuable in a situation where you migrate people away
from log4j. Inevitably, when you are moving people away from what they are
familiar with - there are comparisons. So in the case of migrating people
away from log4j, whe
On 2/15/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
The Service API allows you to enumerate all options. SLF4J has a choice,
#1: Accept the first JAR, report warning that you have others - this is
pretty much the same behavior as we have today - the difference is that with
the static binding me
Hi,
On 2/16/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
> As I said, deploying the correct implementation jar IS a kind of
> configuration, weather you call it that or not.
Exactly, and I think this should be the *only* configuration SLF4J
would ever need. Any solution that requires extra configur
I'm fine with it just picking the first one, but certainly when there is
more than one a very, very clear error message should be output that tells a
user exactly what is wrong and what to do.
On 2/16/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi,
On 2/16/07, Eric Crahen <[EMAIL PROTECTED]>
Hi,
On 2/16/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
> I'm fine with it just picking the first one, but certainly when there is
> more than one a very, very clear error message should be output that tells a
> user exactly what is wrong and what to do.
I've seen a couple of legitimate cases wher
On 2/16/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Exactly, and I think this should be the *only* configuration SLF4J
would ever need. Any solution that requires extra configuration
properties or explicit precedence settings is IMHO too much.
The fact that SLF4J always uses the implementation
Hi,
On 2/16/07, Eric Crahen <[EMAIL PROTECTED]> wrote:
> You don't need to get as complicated as doing precedence, but I still think
> that including the stderr logger as the fallback and default is the way to go.
Sounds OK to me.
> Those couple of legitimate cases you mentioned are valid (logba
As this time SLF4J's scope is to provide a simple to follow recipe for
delaying the choice of the underlying logging system, especially in
complex environments. I can assure you that even such a unambitious
scope is not easy to achieve.
One of the reasons why SLF4J is relatively successful is du
On 2/19/07, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
One of the reasons why SLF4J is relatively successful is due to its
simplicity. SLF4J only does static-binding and ito fails-fast. If
there is no slf4j-binding available SLF4J prints an error message and
dies immediately (it fails-fast).
Still
Earlier versions of SLF4J parsed properties files and instantiated an
ILoggerFactory similar to the way sun.misc.Loader does it. SLF4J "evolved"
into a more primitive solution to make debugging easier (but harder on
SLF4J developers).
I am more interested in refining the current approach as o
Actually no one has presented anything concrete that could be demonstrated
as an actual advantage over what I proposed, which is basically the standard
Java way to do what you are trying to do. I'm not sure you can claim your
solution is an evolved version of the ServiceLoader approach as you were
At 09:58 PM 2/19/2007, Eric Crahen wrote:
>Actually no one has presented anything concrete that could be demonstrated
>as an actual advantage over what I proposed, which is basically the
>standard Java way to do what you are trying to do. I'm not sure you can
>claim your solution is an evolved v
On 2/19/07, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
In practice, the sun.misc.Service may well give the same results as the
current static approach. However, that is not the point. The point is the
difficulty of debugging the logging configuration by the end-user who
might
not be familiar with sun
22 matches
Mail list logo
