Design structure

Question

I have a project being developed with VRaptor and I have a question about the structure of project.

The project I’m developing will be installed in several clients, each with a different structure.

1. I don’t know what the JPA configuration on the client will look like, and how there will be several customers, each with a different configuration, such as can I make the client to configure it correctly? I leave this for the client to configure? I thought to use a datasource ja defined in persistence.xml, but if the customer wants to do the deploy of two instances on the same server, how would that look? Or is there some way of, by doing the re-deploy, do not overwrite the configuration file of JPA?

2. File with some settings, this is also per client and varies much of environment for environment: There is some way to read the file but in the re-deploy do not overwrite the same (keeping settings pre-existing)? Remembering that in this case, depending on the application, will not have access to database to use JPA settings.

I know they exist Environments to handle different configurations, but it has a lot of information that I will not have from the client (mainly bank name and passwords) and would not like to have to create a .WAR specific to each of the customers already with their settings defined.

In PHP I can treat the file overwrite. In this case maybe there is another how to address these doubts, I am open to suggestions.

I would like a solution as practical as possible and can be used in any container (Jetty, WildFly, Tomcat, etc..).

Answer 1

As to the first doubt, the default Java EE architecture is for the application to declare in web.xml what Datasources it depends on and the configuration is performed on the application server at the time of deployment by the client or responsible.

For cases where the client may want two instances of the application pointing to different Datasources, it is up to it to properly configure the server.

Unfortunately, each application server has its own configuration. For example, Tomcat creates a file context.xml for each application with its Datasources. In Websphere and Weblogic it is possible to link resource dependencies to Datasources through the administrative panel.

On the other hand, it is quite possible to ignore the container’s Datasources and leave them to load the application. A very simple way is to load the persistence.xml from a directory when manually instantiating the EntityManagerFactory. The configuration of this directory could be done by environment variable, so the client would still have the flexibility to point to any directory. Being possible to define specific variables for each JVM or for each application (on some servers at least), it would still be possible to have different configuration files for each instance of the application.

Data as user and password are always customer’s responsibility, your application should never load this data within the package.

As for your second doubt, environment-dependent settings should be stored somewhere in the environment.

The vast majority of enterprise applications store system settings or "parameters" in a database. This facilitates management by the client, after all it is only necessary to know a little SQL to do maintenance when necessary.

Another common way is to store the settings in XML, Json or properties files (the latter being more common because it is a Java platform standard). I do not recommend pointing directly to a directory, but using the same technique described above, that is, using an environment variable. The environment variable can be set on several levels: operating system, OS user, JVM, Application Server or for a single application.

In any case, a very important item is to have a roadmap for initial installation and system upgrade.

It is also important to do a kind of application homologation on the various application servers. Unfortunately there are huge differences between them and compatibility is not always so easy to achieve. Some JEE servers come with a library truck that may conflict with what your application has, each has a way to resolve these conflicts.

---

Updating

Specific settings in Tomcat

No Tomcat, the context.xml is the ideal configuration file to point to Data Sources, mainly with regard to databases. Just use the tag <Resource>, in accordance with documentation.

You can also use the file context to define context parameters or application-specific environment variables. See documentation.

Specific settings in Jboss

In Jboss you can configure the Data Sources in the archive standalone.xml, located in a server subdirectory.

There are other files for specific application settings, see documentation here.

These configuration files are inside WAR and as well as the file context.xml of the Tomcat, are called Deployment Descriptors, because they are files that configure the deploy application on a specific server. Each server should have its own, with more or less flexibility.

How to load a specific file per application

You can also upload a different external configuration file for each application or application instance as follows:

1. Set an environment variable by pointing to a configuration directory, for example: /path/to/conf.
2. Create a ServletContextListener to load the settings during the startup of the system.
3. Read the configuration using the configured directory, plus the context path as file name.

Thus if there are two instances of the same application in different contexts, for example /myappinstance1 and /myappinstance2, each will access its own configuration, respectively:

• /path/to/conf/myappinstance1.properties
• /path/to/conf/myappinstance2.properties