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