I know there are several post on this subject already, but they seem to be old or incomplete. So I am reposting to see if I can get a a clear picture how to do this.
Here is my situation, I need to supply to my application the URL of web services that my application is to use at startup. The simplest way to do this would seem to be, to store that address in a flat file on the server. This file will need to be editable by the system adminstrator, so I do not want it stored in the WAR or any complied class on the system.
Where is the best place to store this file?
How do I determine the path of this file when the application is run?
You can give the path to the configuration file as a Java system property to the server. How you do that depends on the server. In Tomcat, for example, you can do it with a -D parameter for the server, environment variables, or in [tt]
conf/context.xml
[/tt] with
environment entries .
Those option might work if I was setting it for the whole Tomcat server, But I need to set it a the webapps level, because I could have various version of the same application pointing to different set of web services.
pass it as a servlet init parameter to your vaadin servlet in your web.xml.
Depending on the application server you are using the init parameters are usually editable in an admin console or the war will be expanded on deployment (Tomcat usually does this) and the admin can edit the web.xml file directly.
The current templates for Vaadin 7 + Servlet 3.0 use @WebServlet for a servlet class to define the servlet and parameterize it, not a web.xml. In that case, you need to create it manually or copy from somewhere (such as from a Servlet 2.4 project).
If the admin edits the web.xml, the problem is that the changes are lost on redeployment.
If you deploy different versions of the same application, perhaps specify a configuration directory with the system property and then concatenate a filename with the version number of the application to that to specify the configuration file.
As you can see from the other answers, there does not seem to be a good solution to this problem that works across all servlet containers (engines). This lack of a solution has surprised me as it would seem to be such a common problem.
While creating/editing a web.xml or context.xml file is one possibility, keep in mind this only works on a servlet container that explodes the .war file into folders & files. While Tomcat does this by default, other containers do not. Especially so for the cloud-based
PaaS services, to which you usually upload a .war without further access to your web app’s contents.
One other suggest I’ve read is calling on a JNDI service at runtime to access configuration information such as the path to (or contents of) a flat file.
This is a problem that needs a solution. Here is why it is important to me. The application I am starting is going to be deployed for many different clients. Each of those cleints will have two sets of web services that the application will connect to, one for production and one for testing. So for each of the instances I will need to be able to supply the URL for the web services specific to that instance of the application. The best way to solve this is to create a configuration file which I can read that holds that information, but from what I can tell there is no way to determine the path of that configuration file.
We had a similar requirement, here is how we did it.
create multiple WARs of your app, one for each client
define an init parameter in the web.xml, name it
clientid and assign the client’s name to it, for example
clientid =vaadin
define a system property that holds a path template for the config file and which includes the clientid, for example
configpath=/path/to/app/${clientid}-config.xml
on startup of your app, get the clientid parameter from the ServletContext and combine it with the path template to get the real path, e.g.
/path/to/app/ vaadin-
config.xml
When using a system property for the path template you will only have to specify it once per server/vm, but you will have to create multiple deployments (WARs) preconfigured with the clientids. This can be done easily in an automated build.