There are three principally different approaches:
- Have the applications pull the configuration every time.
- Have a tool to push the configuration to the applications when it changes.
- Make sure the configuration does not change.
In increasing order of preference. So
3. Make sure configuration does not change.
This is the preferred option. Create suitable aliases for everything that don't need to change.
Domain name for mail server should never change. The host can, but you just redirect the mail.company.com
or mail.inranet
1 to the new host. The same applies for all other network locations. Just create suitable DNS names for them. The same goes for database.company.com
, ldap.company.com
, self-service.company.com
etc. Each web service and web application should have it's own vhost too, so you can move each independently without having to change the dependent applications.
The only case where the host names would change is when when you for example split the database server to two separate databases, but then you have to configure different applications differently, so the central configuration isn't going to help you anyway.
Similarly, each application should have separate account to the database, named as the application and limited to only the operations the application needs. This is for security reasons to minimize the damage if some of the applications is compromised. As a side-effect, it gives each application it's own username and password that don't need to change often, so no more reason for central configuration. Quite contrary; you want to limit the number of places that have each password so when somebody cracks one, the other applications and their accounts are not compromised.
In a sense, it is a shared configuration, but stored in the DNS server. And don't forget DNS can store various other information. There is the SRV record for recording ports where services run, records for storing various kind of encryption keys etc.
2. Have a tool to push the configuration to the applications
There is various configuration management software. These are tools that take care of installing software and deploying configuration across networks. Any non-trivial network should use one to ensure installing security updates.
If you have one, just add appropriate rules to deploy the properties file to all servers that run some application. If you don't, pick one2 and do the same, plus configure it to take care of the security updates.
Note, that these tools can also take care of restarting the application servers when they deploy new configuration or otherwise notify the applications that they need to reload the configuration.
So this is a good option, because such tool is very useful for administering the network in general.
3. Have the applications to pull the configuration.
This requires changing each application in advance. And it won't solve the issue completely anyway, because it suffers the chicken-and-egg problem. You still have to configure the location from which you should pull the rest of the configuration.
File sharing is obviously easiest regarding size of changes to each application. Just remember you'll have to restart the applications too or implement some mechanism for notifying them when configuration is changed, which also reduces the usefulness of the solution.
So I would definitely not recommend this approach of which all your original options are variations.
1You can use arbitrary non-existent top level domain in internal network and it has the advantage that you won't have to change it even if the company is renamed. Just don't use .local
, which is reserved for mDNS.
2Or ask your system administrator to pick one; they are the one who will interact the most with it.
Best Answer
There are a couple options that present themselves in this case.
The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the
getResource
family of calls.Now, if you don't have the property file in the classpath, you could specify it in the system properties which can be accessed through the
System
class as described here.With the invocation of:
java -Dtest="true" -jar myApplication.jar
the value can be extracted with:System.getProperty("test")
and then used either to specify other resources or being a resource itself. While it isn't immediately visible with many application servers, its still there, somewhere. In Eclipse, you can easily see them by going to the run configuration and look at the VM arguments.Similar to the system properties, there are the environment properties accessed through System.getenv. The rest of that set of documents is a good read - The Platform Enviroment. While it speaks mostly to Java SE, nearly everything in it is still applicable and an option for Java EE (I don't think you'll be looking at Java Web Start or Java applets).
Moving to the realm of the application server, we get to the names stored in the context of the application or server.
This value is actually stored in the server configuration itself. The documentation for tomcat. Note that each app server is different and you might get some ugliness in there. The only difference between the database from JNDI and a string is the type that it presents. One is a DataSource, the other is a String.