+1.
I can envision successfully providing technical support for this, successfully
explaining how this works to an implementer.
On Jan 11, 2012, at 3:35 PM, William G. Thompson, Jr. wrote:
> I'd like to move forward on this for 3.5 and it seems like we might
> have come to some consensus. I've restated the proposal below with
> the addition of robust sample config in cas.properties. Could I get a
> straw vote (including non-committers) on the following:
>
> CAS Configuration Principles
> * Simple should be easy, complex should be possible
> * Key config should be easily externalized so that a single war file
> can easily be deployed to multiple tiers or nodes
> * Consistent approach
> * Generally seek to limit the number of files that need to be managed
> in the overlay to make upgrading easier.
>
> Approach
> * Push all defaults to the bean files where they are defined inline
> using the Spring 3.x approach and continue to use cas.properties as
> the deployment override file for simple parameter configuration.
> (simple should be easy)
>
> * Continue to use deployerConfigContext for the rest of a typical
> deployer config (simple should be easy)
>
> * Continue the use of bean xml file override for more complex behavior
> configuration (complex is possible)
>
> * Create new property placeholders and defaults for bean properties
> that could benefit from the new approach (e.g. SSO Session timeouts,
> SLO on/off). (minimize the number of files that need to be managed in
> the overlay)
>
> * Move the propertyFileConfigurer configuration block into
> deployConfigContext.xml (minimize config files)
>
> * Provide robust sample config in cas.properties for all of the
> properties that a deployment might want to override in the simple
> case. (consistent approach)
>
> Bill
>
>
> On Tue, Jan 3, 2012 at 5:49 PM, William G. Thompson, Jr.
> <wgt...@gmail.com> wrote:
>> On Tue, Jan 3, 2012 at 4:53 PM, Scott Battaglia
>> <scott.battag...@gmail.com> wrote:
>>>> Spring 3.x approach:
>>> Q: "Hey, there's this placeholder ${ssoSession.maxTimeToLive:3600} in
>>> ticketExpirationPolicies.xml, where's the value for that set?"
>>> A: "Oh look, the default is right there in-line, bet I could override
>>> that in cas.properties!"
>>>
>>> Your Q/A thing highlighted two things for me:
>>> 1. We need better standards for property naming if we really name things
>>> without the units (i.e. maxTimeToLiveInSeconds) :-)
>>
>> +1 for well named properties.
>>
>>
>>> 2. Having people read through all the Spring XML files rather than
>>> default.properties to locate the values that can be changed/paramaterized
>>> seems like more work for the deployer. I would think properly named
>>> placeholder names all located in one file would provide enough context as
>>> well as give us a single point of reference when questions come up. Do we
>>> want people to care which XML file the properties are in if they don't plan
>>> on overlaying those files?
>>
>> I think the reference issue can be addressed by having robust sample
>> config and explanation right there in cas.properties for all the
>> properties one might want to override (self documenting in a way). As
>> a developer/deployer I'm attracted to the default values set right
>> there in context.
>>
>> On balance both approaches seem to achieve the same results albeit
>> with slightly different qualities. The Spring 3.x approach does it
>> with one less file. Simpler == better?
>>
>> Either way, I think this is an important (thought minor) improvement,
>> and I'm willing to take on this work for 3.5 regardless of which way
>> consensus takes us.
>>
>>>
>>> I think you and I are in agreement though that its time to get it right
>>> (even if we don't completely agree on what "right" is ;-))
>>
>> Indeed.
>>
>> Bill
>>
>>
>>>
>>> Cheers,
>>> Scott
>>>
>>>
>>> On Tue, Jan 3, 2012 at 4:44 PM, William G. Thompson, Jr. <wgt...@gmail.com>
>>> wrote:
>>>>
>>>> What started this discussion was a desired to improve maven overlay
>>>> based CAS deployments for the 3.5 release. The release strategy
>>>> states that in a minor release (i.e. 3.4.x -> CAS 3.5) "CAS maven
>>>> overlays may require minor to moderate changes". So, I tend to want
>>>> to get this right for 3.5 even if it requires some minor to moderate
>>>> changes to existing deployments.
>>>>
>>>> Generally, the first thing I do is externalize cas.properties with the
>>>> goal of having a single war file that can be deployed to multiple
>>>> tiers/nodes without further configuration (i.e. deploy/unpack the war,
>>>> find the right config files, edit/copy the old ones, etc). Having
>>>> some configuration parameters in cas.properties file is great, having
>>>> it in embedded in the war file makes it less convenient for
>>>> single-war-multiple-deployments.
>>>>
>>>> Overtime and many enterprise CAS deployments, I've also noticed that
>>>> logging configuration could also benefit from externalization, which
>>>> gave rise to CAS-1082, subsequent discussions including this one, and
>>>> the discovery that default values for bean configuration could be
>>>> in-lined like so:
>>>>
>>>> <property name="arguments">
>>>> <list>
>>>> <value>${log4j.config.location:classpath:log4j.xml}</value>
>>>> <value>${log4j.refresh.interval:60000}</value>
>>>> </list>
>>>> </property>
>>>>
>>>> We also have the suggestion by Daniel Frett that a default.properties
>>>> be added and loaded before cas.properties to allow default settings to
>>>> be set for stock CAS and not cause issues for deployers when they
>>>> override cas.properties in their own maven overlay.
>>>>
>>>> I agree with Scott's comments regarding coming up with a general
>>>> strategy going forward (3.5+). So, here's a stab at an approach for
>>>> this minor but helpful improvement.
>>>>
>>>> CAS Configuration should follow the following principles:
>>>>
>>>> * Simple should be easy, complex should be possible
>>>> * Key config should be easily externalized so that a single war file
>>>> can easily be deployed to multiple tiers or nodes
>>>> * Consistent approach
>>>> * Generally seek to limit the number of files that need to be managed
>>>> in the overlay to make upgrading easier.
>>>>
>>>> A possible approach:
>>>>
>>>> * Push all defaults to the bean files where they are defined using the
>>>> Spring 3.x approach above and continue to use cas.properties as the
>>>> deployment override file for simple parameter configuration. Continue
>>>> to use deployerConfigContext for the rest of a typical deployer config
>>>> (simple should be easy)
>>>>
>>>> * Continue the use of bean xml file override for more complex behavior
>>>> configuration (complex is possible)
>>>>
>>>> * Create new property placeholders and defaults for bean properties
>>>> that could benefit from the new approach (e.g. SSO Session timeouts,
>>>> SLO on/off). (minimize the number of files that need to be managed in
>>>> the overlay)
>>>>
>>>> * Move the propertyFileConfigurer configuration block into
>>>> deployConfigContext.xml (minimize the number of files that need to be
>>>> managed in the overlay)
>>>>
>>>> Spring 3.x approach:
>>>> Q: "Hey, there's this placeholder ${ssoSession.maxTimeToLive:3600} in
>>>> ticketExpirationPolicies.xml, where's the value for that set?"
>>>> A: "Oh look, the default is right there in-line, bet I could override
>>>> that in cas.properties!"
>>>>
>>>> Bill
>>>>
>>>>
>>>> On Tue, Jan 3, 2012 at 11:05 AM, Scott Battaglia
>>>> <scott.battag...@gmail.com> wrote:
>>>>>
>>>>> On Tue, Jan 3, 2012 at 10:59 AM, Andrew Petro <ape...@unicon.net> wrote:
>>>>>>
>>>>>> I'm ambivalent about the value of this change to introduce an
>>>>>> additional
>>>>>> default.properties to be parsed prior to cas.properties, which would
>>>>>> supersede default.properties' values. It feels like it's adding
>>>>>> complexity
>>>>>> without solving a problem worth solving.
>>>>>
>>>>>
>>>>> Minimizing upgrade pain and placing the defaults in a single location
>>>>> when
>>>>> we realize something should be paramaterized is not worth solving? I'm
>>>>> confused. Especially since not having a mechanism like this in place
>>>>> couldn't add parameters except in major releases or if we spread the
>>>>> defaults throughout all the files (a la the Spring 3 syntax)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Again, this is:
>>>>>>
>>>>>> https://issues.jasig.org/browse/CAS-1084
>>>>>>
>>>>>> and
>>>>>>
>>>>>> https://github.com/Jasig/cas/pull/23
>>>>>>
>>>>>> I'm having trouble empathizing with the problem that this seems to be
>>>>>> trying to solve. Updating the cas.properties file on a CAS version
>>>>>> upgrade
>>>>>> seems like a totally reasonable burden on the upgrader. If CAS started
>>>>>> configuring TGT timeouts in cas.properties, I wouldn't regard it as too
>>>>>> much
>>>>>> to ask *upgrading* CAS adopters to notice the new properties in the
>>>>>> shipping-in-CAS cas.properties and either add these to their localized
>>>>>> cas.properties or delete their local cas.properties and re-fork from
>>>>>> the new
>>>>>> default. I don't see having to update a local cas.properties that
>>>>>> worked
>>>>>> with version 3.4 of CAS to provide the properties required by 3.5 of
>>>>>> CAS as
>>>>>> a problem at all, and I don't value sparing adopters that particular
>>>>>> pain on
>>>>>> upgrade.
>>>>>>
>>>>>> This is different from making new deployers set these values when they
>>>>>> first deploy CAS, since new deployers when first deploying CAS don't
>>>>>> have an
>>>>>> existing cas.properties file that would gum up getting the properties
>>>>>> and
>>>>>> values in the cas.properties shipping in CAS. I would have concern
>>>>>> about
>>>>>> CAS shipping with properties files that don't work. That's different
>>>>>> from
>>>>>> CAS shipping with a cas.properties that does work but worrying that
>>>>>> some
>>>>>> adopters won't use that working cas.properties.
>>>>>>
>>>>>> In my experience, updating the local cas.properties file on an upgrade
>>>>>> to
>>>>>> include added properties just hasn't felt anything like a real problem,
>>>>>> just
>>>>>> a reasonable upgrade practices checklist item. On balance, I'd
>>>>>> probably
>>>>>> rather have the fail-init-on-unfulfilled-placeholder behavior than the
>>>>>> missing-property-is-masked-by-default.properties behavior.
>>>>>>
>>>>>>
>>>>>> Adding default.properties feels like it's adding some complexity.
>>>>>>
>>>>>> Currently:
>>>>>>
>>>>>> Q: "Hey, there's this placeholder
>>>>>> ${cas.securityContext.casProcessingFilterEntryPoint.loginUrl} in
>>>>>> cas-servlet.xml, where's the value for that set?"
>>>>>> A: In the properties file set in propertyFileConfigurer.xml, which by
>>>>>> default is /WEB-INF/cas.properties .
>>>>>>
>>>>>> After this change
>>>>>>
>>>>>> Q: "Hey, there's this placeholder
>>>>>> ${cas.securityContext.casProcessingFilterEntryPoint.loginUrl} in
>>>>>> cas-servlet.xml, where's the value for that set?"
>>>>>> A: Well, it depends. in propertyFileConfigurer.xml, there's a list of
>>>>>> properties files, which by default is /WEB-INF/default.properties and
>>>>>> /WEB-INF/cas.properties. The last-parsed value wins. So, if this
>>>>>> property
>>>>>> is in cas.properties, that's where it's set. But if it's not in
>>>>>> cas.properties, then it's the value in default.properties.
>>>>>>
>>>>>>
>>>>>> It's not the end of the world, but the latter felt harder to explain,
>>>>>> and
>>>>>> the former felt simpler.
>>>>>>
>>>>>>
>>>>>> Currently, if I fat finger a property name in a local cas.properties, I
>>>>>> notice. Under the proposed change, the fat fingering is masked by a
>>>>>> default
>>>>>> value in default.properties.
>>>>>>
>>>>>> Will CAS upgrading deployers be more grateful that we spared them
>>>>>> having
>>>>>> to update their cas.properties files on upgrades, or will they be more
>>>>>> grateful for missing cas.properties properties continuing to fail fast?
>>>>>> It's not clear to me that allowing subsets rather than complete sets
>>>>>> of
>>>>>> properties in cas.properties files is worth losing the
>>>>>> fail-fast-on-missing-properties feature. Would deployers rather have
>>>>>> just
>>>>>> one properties file to worry about, or would they rather have two and
>>>>>> understand what it means for properties to be in which and not the
>>>>>> other?
>>>>>> It's not clear to me that the complexity is worth it.
>>>>>>
>>>>>>
>>>>>> I think I'm -0 for this change, but I don't think it's very important
>>>>>> and
>>>>>> I'll happily help upgrading adopters to understand the
>>>>>> cascading-properties-files approach if CAS implements it.
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jan 3, 2012, at 8:18 AM, Scott Battaglia wrote:
>>>>>>
>>>>>>> I'm not sure I agree with forcing you to add something. If we've
>>>>>>> moved
>>>>>>> a formerly hard-coded property to now being configurable, you
>>>>>>> shouldn't have
>>>>>>> to do anything. If its a new value, we should have a sensible
>>>>>>> default
>>>>>>> without requiring you to choose one (we don't make people set the TGT
>>>>>>> timeouts when they first deploy CAS).
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 3, 2012 at 8:14 AM, Marvin Addison
>>>>>>> <marvin.addi...@gmail.com> wrote:
>>>>>>> I'm really ambivalent about this approach. On the one hand it may
>>>>>>> ease the burden of upgrades when new properties are inevitably added.
>>>>>>> On the other hand it may facilitate upgrades inheriting undesirable
>>>>>>> behavior by default. I personally find it valuable for a deploy to
>>>>>>> break due to a new property missing from out custom cas.properties
>>>>>>> file, which forces me to review the change and consider whether the
>>>>>>> default is in fact desirable.
>>>>>>>
>>>>>>> M
>>>>>>>
>>>>>>> --
--
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
