Configuration file

Question

Configuration file

Navigation

#1 by (0 votes)

1

I have a legacy web (war) application where various environment settings are arranged in XML files, eg the DB path is in 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 WAR of the application according to the client environment I use Jenkins with the Ant Plugin, I set 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 of application configuration.

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

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

Is there any way other than "gambi" that I can at runtime read a configuration file external to cliente Y and do the configuration of war , context.xml and log4j.xml or improve this process some way?

java spring log4j

asked by anonymous 15.12.2016 / 02:34

1 answer

Change menu item accelerator menu Redirect any subdomain to my server

score 0 · Answer 1

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

You should not know the connection (password!) data of the clients. It is for this reason that Java application servers provide a data source that the application consumes.

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

Applications typically 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 staffing is enabled or a configuration tool is available.

Of course it all depends on the model you used to distribute your application, but the important thing is to have the specific configuration of each client separate from it. Think of the 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 such as Jenkins.