I can write the storage mechanism such that its still possible to plug in your own custom algorithm that's more complex than simple JPA queries.
Cheers, Scott On Fri, Dec 10, 2010 at 4:33 AM, Michał Pysz <[email protected]> wrote: > With regards to #2, the JPA example in the trunk does its removal via a >> query (since we fixed how we store the entities). This limits us in >> some sense ( you can't do overly complex clean up mechanisms like >> relying on the isExpired method) but it allows you to replicate the >> basic ExpirationPolicies (i.e. count and timeout) with a query. >> > > We have our own ExpirtaionPolicy instead of default: > org.jasig.cas.ticket.support.TimeoutExpirationPolicy. > > Our own extensions are in isExpired() method. > > We use JPA in mysql. > > Question is: > will be able to use our own expiration policy in cas 4.0 ? > > Our extension allows checking user activity in all connected to CAS systems > and is very important for us. > > Michal Pysz > > > > > > > > > > > > > -- > 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
