axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: [jira] Commented: (AXIS2-4334) Cannot turn off stdout messages when using WSDL 2.0
Date Thu, 15 Oct 2009 20:18:05 GMT
On Mon, Oct 12, 2009 at 14:09, Ceki Gulcu <> wrote:
> Hello all,
> Reading Andreas Veithen's message I would like to make the following
> comments:
>> - SLF4J needs at least two artifacts to work: the API and (a binding
>> to) a concrete implementation. As pointed out in red in the SLF4J FAQ,
>> artifacts from different versions of SLF4J are incompatible with each
>> other. However, in a Maven project you easily end up with a situation
>> where there is a mismatch between the API version and the
>> implementation version. For somebody familiar with Maven and SLF4J
>> (and class loading if the problem occurs in an EAR project e.g.) this
>> is easy to fix, but many developers don't have all this knowledge.
> The FAQ says that you should be careful not to mix different versions
> of slf4j-api and slf4j-binding.  As far as client code is concerned,
> SLF4J api has been backwards compatible since SLF4J 1.0, that is for
> about 5 years.  Moreover, SLF4J 1.5.5 above are all compatible *even*
> if you mix different versions of slf4j-api and slf4j binding. For
> older versions, slf4j will emit a warning telling you to use
> compatible versions for sfl4j-api and for slf4j-binding.  Ironically,
> the incompatibility issues when mixing different versions of slf4j-api
> and slf4j-bindings in versions prior to 1.5.5, stem from this warning
> itself. Talk about shooting oneself in the foot. Sigh.
>> - In general, frameworks using SLF4J cause a dependency hell: some
>> frameworks only depend on the SLF4J API (which in my opinion is the
>> correct approach), but then you need to add additional SLF4J
>> dependencies to your project; other frameworks also introduce
>> dependencies on a particular binding/implementation, but then you need
>> to exclude these dependencies if the choice doesn't match the choice
>> you have made in your project.
> Libraries should not impose a logging implementations on their
> clients. Doing so is contrary to the spirit and raison d'etre of
> SLF4J.  If one of an application's dependencies declares an slf4j
> binding and transitively imposing it downstream then this can be dealt
> with by excluding that slf4j binding in the applications
> pom.xml. While a possibility, I am not aware of any open-source
> library which declares an slf4j binding (and thus transitively
> imposing it downstream).

Looking at the Apache WS universe alone:

- Woden depends on slf4j-log4j12
- Rampart directly depends on slf4j-jdk14 and transitively (via
opensaml2) on jcl-over-slf4j and log4j-over-slf4j.

These are the two projects in Apache WS that I know are using SLF4J
and both include unnecessary dependencies on bindings/bridges.

BTW, it doesn't surprise me to see dependencies on slf4j bindings. The
reason is quite simple: everybody wants to make his own project as
easy to use as possible. If a project X doesn't declare any
dependencies on an slf4j binding, then the user has to declare another
dependency to make library X work. If the user doesn't know SLF4J or
didn't read project X's documentation, he might blame X. On the other
hand, if X declares a dependency on a binding that causes a conflict
with project Y, then the user has no reason to blame either X or Y in

> Whatever the declared SLF4J versions in the dependencies of a project,
> declaring the same version for slf4j-api and slf4j-bnding in the
> applications pom.xml is sufficient to deal with any version
> mismatches.
> Given the above, your statement about SLF4J causing dependency hell
> sounds exaggerated to me.
>> To summarize: commons-logging in general works out of box and you only
>> need to care about it when setting up a particular logging policy;
>> SLF4J causes much more troubles even before you start thinking about
>> logging.
> That is certainly not the feedback we are getting from SLF4J users.
> On the contrary, most SLF4J users are enchanted with the simplicity
> and stability SLF4J offers.
>> That being said, I like the approach used by SLF4J of statically
>> binding a concrete logging implementation to an abstract API and
>> prefer that over commons-logging's approach of dynamic discovery...
> The dependency-hell you describe is a direct consequence of SLF4J's
> static binding policy. As such, it's odd you should like an approach
> but dislike the direct consequences.

I also like drinking, but that doesn't mean that I like all the direct
consequences :-)

There is really no contradiction here. From an architectural point of
view, I like the approach, but from a dependency management
perspective, it is not as nice as I would like. Interestingly most of
the issues point to a missing feature in Maven, namely virtual
dependencies (which would work in a similar way as virtual packages in
Debian's package management system). There is a similar problem with
the Java Activation Framework and JavaMail: there are two
implementations of these APIs, one from Sun and one from Geronimo.
There is no way (other than using explicit exclusions) to tell Maven
that these are substitutes of each other and that it if both appear as
transitive dependencies it would be sufficient to retain one of them
to satisfy the dependencies of the project.

Did you ever think about trying to convince the Maven people to
implement such a feature?

> If you would like to describe the concrete issues you are having or
> have had in the past with SLF4J, you are most welcome to do so on the
> slf4j-user mailing list. I am sure you will be met with an attentive
> ear.
> In any case, my apologies for barging in uninvited into this discussion.
> --
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework for
> Java.

View raw message