[slf4j-dev] jcl-over-slf4j module not building

[Ceki Gülcü]

Hi Jake,

If I understand correctly, the issue is the runtime dependency of SLF4J on 
a binding. Is that correct?

Consider the JDBC API. If you don't have a JDBC driver to connect to your 
database, calls to the JDBC API fail with an exception. At present time, 
the LoggerFactory would throw a NullPointerException. Admittedly, we 
can/should provide a more explicit failure message (by throwing an 
appropriate exception).

Defaulting to a NOP implementation just makes the problem, i.e. the lack of 
a binding, harder to detect. So it boils down to a choice between fail-fast 
and fail-compensate-and-hide. As you might have guessed, my preference goes 
to the former.

Falling back to NOP might be more convenient, but it does not make logging 
easier to debug.

Just my 2c.

At 02:03 AM 2/18/2007, Jacob Kjome wrote:

>Of course with the Service API that Eric Crahen
>is pushing, the NOP implementation could be used
>as the default fallback binding, packaged into
>the slf4j-api.jar, and chosen if no other binding
>is made available by the user.  This would have following benefits...
>
>1.  Remove the imposition of forcing a user to
>provide a separate SLF4J binding jar, since the
>default do-nothing binding would be used as a
>fallback if no other binding is provided.
>
>2.  Remove the imposition of logging when it is
>not desired, and without having to actively provide slf4j-nop.jar
>
>3.  Remove the necessity of generating
>slf4j-nop.jar, as it would already be part of slf4j-api.jar
>
>4.  Reduce user confusion.  Instructions now read:
>
>"To satisfy an SLF4J dependency, simply put
>slf4j-api.jar in the classpath.  Optionally, to
>get logging output, add an SLF4J implementation
>binding in the classpath alongside slf4j-api.jar."
>
>
>With this setup, a user can depend on
>slf4j-api.jar and be done.  Only if logging is
>desired would one need to add a binding that actually performs logging.
>
>
>Thoughts?
>
>Jake
>
>
>At 10:37 AM 2/17/2007, you wrote:
>  >Ceki Gülcü wrote:
>  >> At 11:05 PM 2/16/2007, John E. Conlon wrote:
>  >>
>  >>> Your right, neither do I want to increase the number of classes in the
>  >>> org.slf4j packages.  But we are basically doing the same kind of thing
>  >>> with the second approach as well - exposing our selves to greater
>  >>> coupling by clients.  By exporting the org.slf4j.spi package we are
>  >>> exporting what was once a private package and all classes in it, on to
>  >>> the OSGi package matrix.
>  >>>
>  >>
>  >> The o.s.spi package contains two interfaces, namely
>  >> LoggerFactoryBinder and MarkerFactoryBinder. I am not worried about
>  >> exposing these interfaces into the public.
>  >>
>  >>
>  >That makes sense.  I just committed  the change.  Project now builds
>  >with -Posgi flag.
>  >
>  >End users will still only import o.s while adapters clients will import
>  >both o.s and o.s.spi.
>  >>> Right now we are in a very good position regarding client coupling to us
>  >>> and dependencies we have on other third party jars.  Although we are
>  >>> still using split packages to deliver our Logger service but now for
>  >>> 1.5.0 we do the 'package join' at maven build time versus before we had
>  >>> our clients do it on the classpath.
>  >>>
>  >>
>  >> It's quite nice that we have the technical ability to package all
>  >> SLF4J classes within each binding. However, I am not 100% convinced
>  >> that doing so yields the best user experience, especially as seen by
>  >> developers of libraries.
>  >>
>  >> Assume Alice is the developer of some library, say La. As far as
>  >> Alice is concerned, imposing slf4j-api as a dependency of La is
>  >> acceptable while imposing a binding is not. In SLF4J 1.2, Alice has to
>  >> depend on a binding in La, typically slf4j-simple, and then let the
>  >> user change the binding. It would be more convenient if La depended on
>  >> slf4j-api only. This would allow the end-user to import La as is,
>  >> including its dependency on slf4j-api without change.
>  >>
>  >Perhaps I am not seeing it but, wouldn't it work like it always has?
>  >Alice for her library still imposes the slf4j-api as a dependency and
>  >for testing uses one of the bindings.
>  >> For instance, if Bob was the author of some library, say Lb (how
>  >> original) which depended on La and by transitivity on slf4j-api, Bob
>  >> could use the SLF4J API without additional work.
>  >>
>  >Bob uses La for Lb which carries with it only the slf4j-api dependency,
>  >Bob then uses whatever binding he wishes for testing his Lb.
>  >
>  >Sally now builds an application from Lb and uses whatever binding she
>  >wants but when packaging the application for end user distribution only
>  >needs to add a slf4j binding to the installation zip.  (Even if she
>  >added the slf4j-api and the binding it should still work as expected.)
>  >
>  >John
>  >
>  >_______________________________________________
>  >dev mailing list
>  >dev at slf4j.org
>  >http://www.slf4j.org/mailman/listinfo/dev
>
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://www.slf4j.org/mailman/listinfo/dev

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch