I feel like this relates to the idea of configuring the Java CAS Client via a .properties file, and going further, making the .properties file the *only* way to configure it, retiring the complexity of init params declared at various layers of the web.xml?
Then it would presumably be a single property configuring this in the .properties file, turning on or off renew throughout the client. Configuration of the CAS client library isn't going to get simpler once CAS protocol evolves to do LOA, require authentication methods, etc. It'll be like trying to get various components to agre about "renew", only more so. On Wed, Feb 27, 2013 at 9:55 AM, Marvin Addison <marvin.addi...@gmail.com>wrote: > >> * Prevent misconfiguration by requiring renew to be specified as a > >> context parameter exclusively, where it would apply to all filters > >> that need it. > > > > > > In this instance, what would happen if someone did configure it at the > > filter level? Throw an exception? > > Seems reasonable. I believe we throw for at least some kinds of > configuration errors at present, so that would keep with existing > behavior. > > 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
