Configuration file

Question

I have an app web (war) legacy where various environment settings are arranged in XML files, e.g.: the BD path is in the context.xml

<Context path="/Base"   reloadable="true" crossContext="true">
    <Resource name="jdbc/infodata" auth="Container" type="javax.sql.DataSource"
     maxActive="100" maxIdle="30" maxWait="10000" username="xxxx" 
     password="xxxx"driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"                
     url="jdbc:sqlserver://localhost;instanceName=SQLEXPRESS;databaseName=db" />
</Context> 

To generate the WAR application according to customer’s environment use the Jenkins with the Plugin for Ant, configure a JOB for each different environment.

And I use a script of Ant to load the configs of each environment and write in all XML's application configuration.

This involves context, config of log4j and configs of services of spring.

The trouble with that is I get a lot of files war equal only with variaveis different environment, and the system versions are "zicadas". While cliente X is in the version 56, cliente Y is in the 2 but are identical, for example.

Is there any way other than "Gambi" that I can at runtime read an external configuration file to war and configure the context.xml, log4j.xml and spring-services.xml or improve this process in any way?

Answer 1

The problem is the lack of an appropriate separation between the application code and the configuration.

You should not know the connection data (password!) of clients. This is precisely why Java application servers provide a data source that the application consumes.

A common way is that each client has a Tomcat (or any application server) with specific settings and the distributed WAR is the same for everyone. When the application boots, it reads the settings that are in each client.

Applications usually have a set of default settings for logging and flags of the system. Specific settings can be made by the support or by the client itself if there are enabled personnel or a configuration tool.

Of course it all depends on the model you use to distribute your application, but the important thing is to have the specific configuration of each client separate from it. Think of configuration as a second database.

The only cases where it is possible or desirable to have the configuration together with the application are for local or automated testing, for example, on a continuous integration server like Jenkins.