Regarding the first question , the default Java EE architecture is that the application declare in web.xml of which DataSources it depends on and the configuration is performed on the application server at the time of deploy by the client or responsible person.
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, in Tomcat a context.xml file is created for each application with its DataSources. In Websphere and Weblogic, you can link resource dependencies to DataSources through the administrative panel.
On the other hand, it is quite possible to ignore the DataSources of the container and let them load the application. A very simple way is to load persistence.xml from a directory by manually instantiating 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. Since it is 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 such as username and password are always the customer's responsibility, your application should never load this data into the package.
As for your second question , environment-dependent settings must be stored somewhere in the environment.
The vast majority of enterprise applications store the system settings or "parameters" in the database. This makes it easy to manage on the part of the client, after all it is only necessary to know a little SQL to do the maintenance when necessary.
Another common way is to store the settings in XML, Json, or properties files (the latter 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 defined 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 make a kind of approval of the application 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 those conflicts.
Update
Tomcat specific settings
In Tomcat, context.xml is the ideal configuration file to point to Data Sources , especially for databases. Just use the <Resource> tag, as per documentation .
You can also use the context file 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 file standalone.xml , which is in a subdirectory of the server.
There are other files for application-specific settings, see documentation here a>.
These configuration files are inside the WAR and, like the Tomcat context.xml , are called deployment descriptors because they are files that configure < in> deploy section of the application on a specific server. Each server should have its own, with more or less flexibility.
Uploading a specific file per application
You can also load a different external configuration file for each application or instance of the application as follows:
Set an environment variable pointing to a configuration directory, for example: /path/to/conf .
Create a ServletContextListener to load the configuration during the startup of the system.
Read the configuration using the configured directory, plus the context path as the filename.
In this way, 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
