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
Jérôme,
Thanks for the cookie recipe.
I had to try – was surprised that it worked at all and wanted to confirm my
understanding. It doesn’t really work though if users can’t log out ☺ Waiting
for the political wheels to turn before getting complicated.
Curtis Long
Unix Administrator
Durham Col
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.
Thanks Stephan. Originally the requirement was to fallback to an alternative
auth module. However, after the recommendation from you and Jerome, it sounds
like a bad idea. So we are not in favour of the same.
Regards,
Prasad
From: Stephan Arts [mailto:sa...@cosmos.esa.int]
Sent: 06 February 201
Hi Prasad,
I think that would be a good solution for what you are describing. I was
under the impression you were referring to a fallback scenario in case
your own CAS server was not available.
Regards,
Stephan
On 06/02/15 09:50, Mahantesh Prasad Katti wrote:
>
> Thanks Stephan and Jerome. Th
Thanks Stephan and Jerome. The requirement is something like this. We have a
product used by multiple customers. It is likely some of them have a CAS in
their ecosystem and others may not. So we wanted to provide both modes of
authentication. One way that i know we can accomplish is to define a
Hi,
I agree with Jérôme, the simplest and most robust solution is to have 2
(or in our case 4) CAS servers running in a cluster with a multi-master
LDAP backend. Put a load-balancer in front of your CAS servers and
you're done.
Okay, on second thought... Maybe not the simplest, but it is very
