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

Jacob Kjome hoju at visi.com
Mon Feb 19 22:44:02 CET 2007 

Quoting Ceki Gülcü <listid at qos.ch>:

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

Yep

> 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).
>

Ceki, are you arguing for the Service API here?  Kidding.  I know you're not
intentionally, but in a way you are.  And keep in mind that the only reason the
JDBC situation is set up like this is that the API is provided by the JDK as a
standard extension.  I just looked at the Oracle driver and it ships the entire
javax.sql package along with its implementation in the same jar.

> Defaulting to a NOP implementation just makes the problem, i.e. the lack of
> a binding, harder to detect.

Not really.  NOP would be the oddball.  It's use as a fallback default would go
along with explicit messages to System.err stating that it's quite possible one
forgot to provide a logging implementation.  One can choose to ignore the
message, knowing that one doesn't want logging or one can act on the message
and provide the SLF4J binding of choice.

> 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.
>

Well, actually it would be fail-compensate-and-report

> Falling back to NOP might be more convenient, but it does not make logging
> easier to debug.
>
> Just my 2c.
>

I think it is both more convenient and easier to debug.  As Eric pointed out in
another thread, it would be possible to provide messages about multiple
bindings on the classpath and alert the user that they probably did not intend
this and direct them how to correct the situation.

BTW, if SLF4J used the Service API, I think it would have to be a home grown
one.  Clearly SLF4J cannot depend on com.sun.* or JDK1.6.  So, the Service
stuff would have to be written from scratch and shipped with the API.  I'm not
sure how involved this would be as I'm not sure how much plumbing code would
need to be written.  Eric, can you address this point?


Jake

> 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
>
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev
>

More information about the slf4j-dev mailing list