[
https://issues.apache.org/jira/browse/JCR-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-717.
-------------------------------
Resolution: Fixed
SLF4J dependencies upgraded to 1.3.0 in revisions 511632 and 511637.
After this change jackrabbit-core and the other jar components only have a
compile-scope dependency to slf4j-api and any client applications need to
explicitly declare an appropriate slf4j implementation dependency to avoid a
ClassNotFoundException at runtime. The jackrabbit-jca and jackrabbit-webapp
projects do exactly this, they both depend on slf4j-log4j12, i.e. use log4j 1.2
for logging just as before.
In revision 511639 I also moved the second half of the JCR-683 commons-logging
workaround from jackrabbit-webdav to jackrabbit-webapp. The commons-httpclient
dependency of jackrabbit-webdav introduces a transitive compile-scope
dependency to commons-logging, which was previously replaced by the
jcl104-over-slf4j adapter library already in jackrabbit-webdav. The adapter
workaround was moved to jackrabbit-webapp where we already do specify log4j as
the selected logging framework. Thus other users of jackrabbit-webdav will
either need to configure and use commons-logging, or to use a similar mechanism
with the jcl104-over-slf4j adapter.
> Upgrade to SLF4J 1.3
> --------------------
>
> Key: JCR-717
> URL: https://issues.apache.org/jira/browse/JCR-717
> Project: Jackrabbit
> Issue Type: Improvement
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> Version 1.1 of the SLF4J logging facade was recently released. It contains no
> functional improvements that we'd need, but is split to a separate slf4j-api
> library and a set of backend-specic logging adapters. This would allow us to
> avoid exposing log4j as a transitive dependency for projects that depend on
> Jackrabbit.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
