Maybe adopting JodaTime would give CAS a good way to model durations? We've been getting a huge amount of value out of using this library in uPortal. JodaTime has a nice Duration class that allows you to create durations by second, minute, day, etc. http://joda-time.sourceforge.net/api-release/org/joda/time/Duration.html.
- Jen On Mar 13, 2012, at 6:49 PM, Andrew Petro wrote: > Getting beyond milliseconds for timeouts feels like it will be more usable > for administrators configuring CAS servers. Which is to say, I agree with > the improvement intention articulated in CAS-1104. [1] Will anyone miss > being able to define timeouts in partial seconds, or is the > milliseconds-centric approach just adding three zeros to the end of each > configuration value? I expect the latter. > > There are some spots where minutes or even hours would be desirable as > configuration units. > > Yet, XML durations feels a complicated pill to swallow. They'd end up > looking something like > > PT5M > > for five minutes, a reasonable time to live for a service ticket, but > accidentally omitting the T > > P5M > > would mean five months, which is decidedly too long for a service ticket to > remain valid. > > > > This [2] looks beautifully literate: > > <bean id="grantingTicketExpirationPolicy" > class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy" > > p:maxTimeToLiveInSeconds="28800" > p:timeToKillInSeconds="7200"/> > > Units are obviously seconds (says so right in the name). > > And yet, those values look like they really want to be hours, in that all the > numbers of seconds here are multiples of 3600. > > > I thought what Dima did here [2] was pretty interesting: > > <util:constant id="SECONDS" > static-field="java.util.concurrent.TimeUnit.SECONDS"/> > <bean id="serviceTicketExpirationPolicy" > class="org.jasig.cas.ticket.support.MultiTimeUseOrTimeoutExpirationPolicy" > c:numberOfUses="1" c:timeToKill="10" c:timeUnit-ref="SECONDS"/> > > That also reasonably literately says 10 seconds, without having to prepend > anything with "P" and get any "T"s into the right spot. > > > So maybe the former should be > > <util:constant id="SECONDS" > static-field="java.util.concurrent.TimeUnit.SECONDS"/> > <util:constant id="MINUTES" > static-field="java.util.concurrent.TimeUnit.MINUTES"/> > <util:constant id="HOURS" > static-field="java.util.concurrent.TimeUnit.HOURS"/> > > <bean id="grantingTicketExpirationPolicy" > class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy" > > p:maxTimeToLiveUnit-ref="HOURS" > p:maxTimeToLive="8" > p:timeToKillUnit-ref="HOURS" > p:timeToKill="2"/> > > > And then, going after preferring constructor arguments [3] rather than > properties for required set-once configuration, and making use of that > beautiful c: prefix [4] to keep it literate: > > > <bean id="grantingTicketExpirationPolicy" > class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy" > > c:maxTimeToLiveUnit-ref="HOURS" > c:maxTimeToLive="8" > c:timeToKillUnit-ref="HOURS" > c:timeToKill="2"/> > > > > How's that? We get units, it's constructor-injected, and the XML > configuration remains literate. > > If something like that does meet all the needs, then it ought to be doable to > find all the places where custom CAS code is currently configured in > milliseconds and instead accept a TimeUnit and a long. I'd think that can be > nailed for 3.5, how many such configuration points can there possibly be? > I'm willing to hunt them down and nail them if this solution is going to > otherwise fly. > > And I do think it's an improvement over configuration in milliseconds. > > Andrew > > [1]: https://issues.jasig.org/browse/CAS-1104 > > [2]: > https://github.com/Jasig/cas/blob/cbe1fa57ecda5c20ef892378c4742d5d528aa305/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketExpirationPolicies.xml > > [3]: > https://github.com/Jasig/cas/commit/11709f8294beb4cb1ffd699ca5cce6c14ef4383f > > [4]: > http://static.springsource.org/spring/docs/3.1.0.M1/spring-framework-reference/html/beans.html#beans-c-namespace > > > > On Mar 13, 2012, at 10:00 AM, Marvin S. Addison wrote: > >> Some recent commits have added additional properties/constructors to a >> couple ExpirationPolicy components that will be leveraged in the default >> Spring contexts for 3.5 and presumably future releases that change the >> default time interval from ms to s: >> >> https://github.com/Jasig/cas/commit/11709f8294beb4cb1ffd699ca5cce6c14ef4383f >> https://github.com/Jasig/cas/commit/a08f601e71b0abf98f5cda666144bce09c957638 >> >> While this may provide consistency for the expiration policies that are >> configured by default, the other ExpirationPolicy components still use >> milliseconds. Moreover, we have used ms fairly consistently for time >> intervals throughout the CAS codebase. >> >> The intent to increase convenience and clarity of time intervals for >> deployers is laudable and reasonable, but the changes above don't go >> nearly far enough. If tight timelines are limiting the scope of changes to a >> few components, then it would be better to wait until we have the time and >> resources to develop a flexible time interval facility and apply it >> consistently. XML durations, http://www.w3.org/TR/xmlschema-2/#duration, are >> one of a number of reasonable standards we might consider. >> >> I strongly recommend that we do no further harm with capricious >> component interface changes and tackle the issue thoroughly and >> consistently after the 3.5 release. I propose a Jira issue to track >> that effort and link it with the two issues behind the changes above. >> >> M >> >> -- >> 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-dev > > > -- > 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-dev > -- 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-dev
