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:
>> > scott.battag...@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:
>> > 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:
>> scott.battag...@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: 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
