Multiple projects using a single "properties" file

Question

Multiple projects using a single "properties" file

Navigation

#1 by (0 votes)

2

I have a product that is distributed in several independent MAVEN WEB projects that access a single MYSQL database. I decided to split it into several projects so that each module stays on a different server, dividing the load. And also because they are modules with different purposes and it did not make sense to deliver everything in one package.

It happens that these modules have some common features and I've created a library with common classes, so all projects use this library.

In the same way, each module has its own * .properties file. I would like to unify these files into a single * .properties file, so that all modules could access it, making it easy to change at runtime. I thought about putting it in this library, but I would still have the same problem, since each project has its own JAR from that library, in addition, it would be necessary to extract the JAR, change the * .properties, and compress it again, which makes it unfeasible the procedure.

It is also possible to place all these keys in a table in the database, since all modules access it.

Is there a more elegant solution to this situation?

java-ee

asked by anonymous 15.04.2014 / 16:52

1 answer

SQL does not work on another device after publishing to the web caches_page in rails 3 does not work in production [closed]

score 0 · Accepted Answer

The basic solution is to put the configuration into databases and load the data at startup of each application.

Another possibility is to define a network directory and read its properties file. All machines (servers) would have to see this directory, which can be mapped to facilitate changes.

A third option is to make the settings available via webservice and a "central" server that each application queries during startup.

To update the settings at runtime, there could be a timer to reload them in time slots or even a specific functionality for that (a "reload" button somewhere). This depends on many of the change requirements, that is, whether there can be user interaction and frequency of changes.

As for the library jar, unfortunately there is no magic. Jar should be distributed in each application, with or without the properties. If there are multiple applications on the same server, a single jar can be imported into classpath through a configuration on your application server. This would avoid doubling the jar on the same machine.

If this jar is frequently updated, its update could be automated via scripts that scan a location on the network and directly update the libs of published systems. However, you will probably need to reinitialize your applications with this script. In general I think it's an exaggeration. No configuration module should change that much.

Anyway, some ideas were based on abstract requirements. If there is any more specific detail or requirement about your issue, please edit your question to reflect this.