You can stick with the older version of Spring Web Flow. Sent from my Verizon Wireless BlackBerry
-----Original Message----- From: Raymond D Walker <[email protected]> Date: Mon, 23 Aug 2010 23:58:08 To: <[email protected]> Reply-To: [email protected] Subject: Re: [cas-user] Login losing service To make an attempt at resolving my issue, I have added the following to my pom.xml <dependency> <groupId>org.springframework.webflow</groupId> <artifactId>spring-webflow</artifactId> <version>${spring.webflow.version}</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> </exclusion> </exclusions> </dependency> <properties> <spring.webflow.version>2.1.0.RELEASE</spring.webflow.version> </properties> Reason being it's the only spring version that changed... The service still disappears when letting a sessionid timeout in the browser (default 5min) & then logging in successfully. Any ideas on this one? Raymond Walker Software Systems Engineer Sr. ITS Northern Arizona University On Aug 23, 2010, at 3:43 PM, Raymond D Walker wrote: > If this is the changeset you're taking about: > https://developer.jasig.org/source/changelog/jasigsvn?cs=21004 > > ...then I'm having some issue deploying this fix with our maven overlay... > > I believe the trunk's pom.xml shows your modification of: > <spring.webflow.version>2.1.0.RELEASE</spring.webflow.version> > > where I believe we're still getting the > <spring.webflow.version>2.0.8.RELEASE</spring.webflow.version> > > via the 3.4.2 or 3.4.2.1 branches in the repository: > http://oss.sonatype.org/content/repositories/releases/ > > Any easy fix for this? Currently trying to massage this into our pom.xml but > am unsure as to the consequences. > > Raymond Walker > Software Systems Engineer Sr. > ITS Northern Arizona University > On Aug 23, 2010, at 5:13 AM, <[email protected]> > <[email protected]> wrote: > >> You're probably running into the issue where your user has waited until the >> http session has ended before hitting submit. In CAS 3.3.5 this would have >> merely resulted in having to resubmit the form again. In 3.4 there was some >> change to the underlying Web Flow behavior that changes the url when thiss >> happens. We have a fix in trunk to re-append the behavior after Web Flow >> removes it. If you look for the JIRA issue you'll find the commits >> associated with it. >> >> Cheers >> Scott >> >> Sent from my Verizon Wireless BlackBerry >> >> -----Original Message----- >> From: Raymond D Walker <[email protected]> >> Date: Mon, 23 Aug 2010 04:53:09 >> To: <[email protected]> >> Reply-To: [email protected] >> Subject: [cas-user] Login losing service >> >> We're currently having an issue with a small amount of logins. Roughly ~<%.5 >> are loosing their service and being directed to the generic "/cas/login" >> page. >> >> Basics: >> CAS 3.4.2 running on Tomcat 5.5.27 >> front ended with Apache 2.2.11 & mod_proxy_ajp >> >> Action: >> User browses to URL that is CAS protected. >> User is redirected correctly to CAS login with correct service attached >> (verified via logs) >> User logs in with correct name/password >> -Apache logs login request with valid service attached. >> -CAS logs user has supplied good credentials. >> -Apache logs request for generic login page "/cas/login" >> >> Users: This happens to random users, but is not replicable when user clears >> cookies/credentials and tries logging back in. >> Times: Happens at random times, though it seems to be a steady "percentage" >> of overall logins and somewhat evenly spaced out (ie. no groupings of these >> errors at the same time.) We're seeing something around a half percent, >> where at low volume times disappears off the map. >> Service: everything from high volume services, to barely un-used test pages. >> >> Not so basics: >> We've suspected this happening in CAS 3.3.5 but seems to be rearing it's >> head in 3.4.2 a bit more... we suspected it was rooted in our JBoss >> configuration, and needed an excuse to move over to Terracotta. Both have >> similar results. At this point we went to a one node setup, running the >> default ticket registry, removing any High Availability issues. Alas, the >> result (percentage of lost service) stays the same. >> >> The best we can come up with at this point is that somewhere along the line >> the user's sessionid is corrupted or lost, but the user's successful login >> is attached to a new sessionid, though their service is lost. I documented >> something similar in my earlier JBoss/Terracotta posts to this list. >> >> Any ideas or suggestions on this one? >> >> Currently I'm leaning towards a possible issue with mod_proxy. Tomorrow >> includes upgrading the 32bit version of Apache to 64bit and a few more ideas >> up our sleeve. >> >> Raymond Walker >> Software Systems Engineer Sr. >> ITS Northern Arizona University >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
