You can actually specify multiple files so you can include the original
one.  If you add your local file second then it will overwrite comparable
values in the first one:
http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/core/io/support/PropertiesLoaderSupport.html#setLocations(org.springframework.core.io.Resource[])

(sorry Google returned the 2.5.6 docs but I am assuming it hasn't changed
much)


On Fri, Jun 13, 2014 at 9:35 AM, Dmitriy Kopylenko <[email protected]>
wrote:

> I’ll try. There is nothing special how we (at Unicon) define the CAS props
> and the referenced overlay is just an example of best practices of what
> worked really well for our CAS deployments. As Scott explained, it is
> 'either OR' situation in the way that the PPC
> (PropertyPlaceholderConfigurer) is defined - it’s either the default one in
> CAS which looks for the properties file in the WAR’s class path, or the one
> you redefine with whatever properties resource location you choose. I think
> it’s possible to have a complex PPC definition to combine 2 (or more)
> locations, but I personally don’t see the benefit for such complexity.
>
> Best,
> Dmitriy.
>
>
> On Jun 13, 2014, at 9:26 AM, Scott Battaglia <[email protected]>
> wrote:
>
> No, its not easy to understand.  You overwrote where it would look for the
> file but you're still expecting it to find the file.  If you want CAS to
> still leverage the default file, you should have your property configurer
> reference both.
>
> I can't speak for how Unicon defines their overlay.  You'll have to let
> one of them chime into this thread. (they're usually really good about
> responding)
>
>
>  On Fri, Jun 13, 2014 at 9:20 AM, Zac Harvey <[email protected]>
> wrote:
>
>>  Thanks again Scott,
>>
>>
>>
>> But it’s easy to understand why I’m expecting CAS to behave the way I do.
>>
>>
>>
>> Take a look at:
>>
>>
>>
>>
>> https://github.com/Unicon/unicon-cas-overlay/blob/master/src/main/webapp/WEB-INF/spring-configuration/propertyFileConfigurer.xml
>>
>>
>>
>> That project says “Hey CAS, look on the file system for
>> /etc/cas/cas.properties.”  Then, at:
>>
>>
>>
>>
>> https://github.com/Unicon/unicon-cas-overlay/blob/master/etc/cas.properties
>>
>>
>>
>> In that cas.properties files, several of the properties that exist at the
>> link you sent me (
>> https://github.com/Jasig/cas/blob/master/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/propertyFileConfigurer.xml)
>> aren’t defined.
>>
>>
>>
>> So again, it’s unclear as to what properties CAS needs by default, and
>> because of that, it’s unclear how CAS supplies its own defaults when the
>> supplied cas.properties file omits them. Thanks again!
>>
>>
>>
>> *From:* Scott Battaglia [mailto:[email protected]]
>> *Sent:* Friday, June 13, 2014 9:13 AM
>>
>> *To:* [email protected]
>> *Subject:* Re: [cas-user] CAS: Please confirm cas.properties behavior
>>
>>
>>
>> You've re-defined this file:
>>
>>
>> https://github.com/Jasig/cas/blob/master/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/propertyFileConfigurer.xml
>>
>> by creating your own.
>>
>>
>>
>> So I don't understand why you think it would still apply those properties
>> if that bean definition no longer exists.
>>
>>
>>
>>
>>
>> On Fri, Jun 13, 2014 at 9:07 AM, Zac Harvey <[email protected]>
>> wrote:
>>
>>  Thanks Scott,
>>
>>
>>
>> So can you (or anyone else) confirm that my suspicions about default
>> cas.properties behavior is correct? Also, Scott, is the cas.properties link
>> you reference below simply the minimal props I need to define inside my
>> cas.properties file?
>>
>>
>>
>> *From:* Scott Battaglia [mailto:[email protected]]
>> *Sent:* Friday, June 13, 2014 8:02 AM
>> *To:* [email protected]
>> *Subject:* Re: [cas-user] CAS: Please confirm cas.properties behavior
>>
>>
>>
>>
>> https://github.com/Jasig/cas/blob/master/cas-server-webapp/src/main/webapp/WEB-INF/cas.properties
>>
>>
>>
>> On Fri, Jun 13, 2014 at 7:15 AM, Zac Harvey <[email protected]>
>> wrote:
>>
>>  I’m seeing some behavior that **appears** to be default CAS behavior,
>> but it’s just not working like I expected and it has me stumped.
>>
>>
>>
>> If I create a brand new project directory, and only stick a pom.xml in it
>> (hence using 100% CAS defaults, no overrides or customizations whatsoever)
>> and run “mvn clean package”, I get a cas.war that deploys to Tomcat just
>> fine (using CAS 4.0.0 and Tomcat 7).
>>
>>
>>
>> But then I go ahead and add a
>> src/main/webapp/WEB-INF/spring-configuration/propertyFileConfigurer.xml
>> file, that has the following contents:
>>
>>
>>
>>                 <bean id=”propertyPlaceholderConfigurer”
>> class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”>
>>
>>                                 <property name=”ignoreResourceNotFound”
>> value=”true” />
>>
>>                                 <property name=”locations”>
>>
>>                                                 <list>
>>
>>
>> <value>file:/home/myuser/cas.properties</value>
>>
>>                                                 </list>
>>
>>                                 </property>
>>
>>                 </bean>
>>
>>
>>
>> And, just to see what happens, I intentionally **do not** put a
>> cas.properties file under /home/myuser.  Now when I run “mvn clean package”
>> and deploy the cas.war to Tomcat, I get all sorts of exceptions in the
>> Tomcat log, complaining about there not being a host.name property
>> specified (which is true since I don’t have a /home/myuser/cas.properties
>> file).
>>
>>
>>
>> I **expected** CAS to look for /home/myuser/cas.properties and, if it
>> can’t be found, to use the same defaults that were applied before I added a
>> propertyFileConfigurer.xml file. Instead, it looks like CAS looks for
>> /home/myuser/cas.properties, and if it can’t be found, just gives up and
>> doesn’t try to apply any defaults at all.
>>
>>
>>
>> Is this normal CAS behavior?  If so, what are all the other properties
>> (besides host.name) that I need to provide CAS with, and where is this
>> documented?
>>
>> --
>>
>> 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
>>
>>   --
>>
>> 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
>>
>>  --
>> 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
>
>
> --
> 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

Reply via email to