Correction, there were missing libraries apparently, as the RPMs we
created for our CAS server were not completed as expected. Go figure.
I'm kind of surprise our code was not mentioned in the stack trace, as
it was calls to our code that broke it. So, when we restored the stock
login-webflow
I have found the problem.
The contractor who originally ported our customizations from CAS 2 to
CAS 3 was attempting to fix a problem that did not exist. He was just
using the spring webflow inappropriately. He seemed to be attempting to
get around a problem with his custom login jsp, where
did anybody checked the aspects aop jar version that is incompatible with
new cas
Lava Kafle
Ms by Research in Computer Science
Kathmandu University
cell:
9841224387
9801034557
On Tue, Jun 5, 2012 at 5:59 PM, Marvin S. Addison
wrote:
> Okay, looking at the source with a stack trace doesn't h
Okay, looking at the source with a stack trace doesn't help me. I'm
betting spring is mangling the stack trace like it usually does.
Nope, it's much more interesting than that. Inspektr is likely eating
the meaningful exception since it's throwing an NPE from a finally block
that's being exec
Hi Guys,
Yep, same problem as...
http://groups.google.com/group/jasig-cas-user/browse_thread/thread/188227cf7c2e5053
We are also attempting to get Banner 8 Luminis portal working with CAS.
Le 12-06-04 12:26 PM, Trenton D. Adams a écrit :
Hi Guys,
Okay, looking at the source with a stack trace
Hi Guys,
Okay, looking at the source with a stack trace doesn't help me. I'm
betting spring is mangling the stack trace like it usually does. I've
seen this happen on other projects. What a nightmare. :P
Can anyone make sense of this stack trace? I'm sure there's no code on
line 1 of Cen
