I'm going to guess you might have a classpath issue.
If you're putting SLF4J in the parent classpath (TOMCAT/lib), I don't think
it will be able to look into a child for the binding (logback). I think it
would only work the other way.
I am not a Tomcat classpath expert though as I haven't used T
I eventually came up with something that works that's basically consistent
with what I think you're saying, though I'm not sure about transitively
getting the slf4j-api class since I encountered a fatal error until I
explicitly provided that myself.
As for the binding, my initial thought was to us
SLF4J is very similar to Commons Logging in that there is an API jar and
then one or more implementations/bindings.
You should have transitively gotten the slf4j-api class (since we would
have to compile against it) and you would have to provide the binding that
maps to your logger of choice (Logb
Hi Baron,
I don't have an answer to the change in logging libraries, but if you
are including the cas-client via Maven, Ivy, Gradle, etc., then the
client's dependencies should automatically be resolved. Might be worth
using a simple pom.xml with that as a dependency and see what gets included.
We're using the Java cas-client (3.3.3) to provide RemoteUser
authentication for our Shibboleth IdP service.
This version seems of the cas-client seems to require slf4j where our
previously used version (3.2.1) didn't(?). I encountered the the following
error until I put a copy of slf4j-api-1.7.10
