On Tue, Mar 13, 2012 at 9:49 PM, Andrew Petro <ape...@unicon.net> 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
Indeed. [snip] > > 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. +1 Bill > > 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 cas-dev@lists.jasig.org as: ape...@unicon.net >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: wgt...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
