[
https://issues.apache.org/jira/browse/WODEN-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764666#action_12764666
]
Sagara Gunathunga commented on WODEN-71:
-----------------------------------------
some comments from Ceki Gulcu --
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).
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.
> Logging Strategy and Implementation for Woden
> ---------------------------------------------
>
> Key: WODEN-71
> URL: https://issues.apache.org/jira/browse/WODEN-71
> Project: Woden
> Issue Type: New Feature
> Components: Parser
> Reporter: Graham Turrell
> Assignee: Sagara Gunathunga
> Fix For: M9
>
>
> Woden currently does not use a logging reporting framework. A suitable
> framework should be agreed upon. Apache log4j is proposed.
> One immediate application for the framework would be reporting all candidate
> URI's that pass through the Woden URI Resolver.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
