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

[Ceki Gülcü]

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.

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

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.

>If I review what we want with this fix, it is to give to our adapters a
>common functionality for providing location awareness.  (Am I right?)

I think so. The LocationAwareLogger allows logger adapters (as shipped
in each binding) to extend the org.apache.Logger interface so that the
jcl104-over-slf4j bridge can take advantage of the caller location
extraction capability of the underlying logging system. (Otherwise,
the location info is off by one stack trace element.)

>IMO a better way to do this is to create a new utilities package with
>this interface in it, that way we can offer it for inclusion in our
>bindings projects along with the private binding packages
>org.slf4j.impl, org.slf4j.spi, org.slf4j.helpers.  These binding bundles
>would then offer both org.slf4j and something like a org.slf4j.utilities
>to clients and adapter bundles.  Clients bundles would not see this
>package, and adapter bundles would import both from the binding bundles.
>   That's the  theory at least.

Well, I think that a o.s.utilities package would minimize the number
of public classes. However, leaking LoggerFactoryBinder and
MarkerFactoryBinder interfaces into the public should not have a
practical effect. At least I can't think of any impact (famous last words). :-)


>WDYT?
>John

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