2

My goal is to make SpringApplicationContext.xml and all environment specific properties file out of war file, so that the war file is environment independent.

1. Externalize properties file: I think I need to do something like this.. 

<property name="searchSystemEnvironment" value="true" />
<property name="locations">
    <list>
        <value>file:///${MY_ENV_VAR_PATH}/my.app.config.properties</value>
    </list>
</property>

Also discussed here, how to read System environment variable in Spring applicationContext

2. Externalize SpringApplicationContext.xml: I may use Spring boots feature of Externalized Configuration.

http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html

Q1: Being new to Spring boot, I am not sure if I can safely delete/unselect all the unnecessary features that come with Spring boot and apply those to my project? I see Spring boot is for project which are getting started from scratch, in my case I am working on a mature project.

Q2: Is Externalizing configuration an antipattern and am I going in the right direction with my above approach?

Community
  • 1
  • 1
Himalay Majumdar
  • 3,883
  • 14
  • 65
  • 94

1 Answers1

1

As I have not used Spring boot, I can only answer your second question. Externalizing configuration is definitely not an anti-pattern. It adds to flexibility and eases (re)deployment in customer sites. In fact I am talking about externalizing properties, not context configuration. Here is an example of an externalized properties in tomcat I have used before:

<bean name="appProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">  
        <property name="locations">
            <list>
                <value>classpath:config-default/app.properties</value>
                <value>file:${CATALINA_BASE}/conf/app-properties</value>                    
            </list>
        </property>
        <property name="ignoreResourceNotFound" value="true" />
    </bean>

The first entry is internal and sets default properties. The second entry refers to an optional externalized file that the customer can edit to override default properties. You may also deliver a subset of the first file with the properties you consider safe for the customer to modify. Then in each update the setup in the target environment is preserved.

gregdim
  • 2,031
  • 13
  • 15