In projects I work(ed) on, deployment parameters - such as storage path or DB login - are usually given through a parameter file, which is stored in the war file.
I find that unsuitable because those values needs to be changed each time the webapp is packaged for a different deployment (dev vs prod, change of executing computer). The source code being versioned, this makes it even more bothering.
Is there some better option to pass parameters such as listed above?
By better, I mean:
practical: simple to setup, change and explain to others
separated from the war
as independent as possible to the web container (if dependent, I'm using tomcat in prod)
Edit
I chose the answer of #aksappy to reward the work done in the answer and because it provided several methods using standard tools. However, depending on the context I could go for any other solutions:
method of #Necreaux has best simplicity
method of #Luiggi Mendoza has a good design and is still simple
method of #OldCurmudgeon would be a really good one if the code covered other cases.
You can use a multitude of things based on your environment. Here are somethings which may be considered
Use datasources
The datasources defined in the server context removes the hard wired dependency of managing db configurations and connection pool from the web application. In Tomcat, this can be done as below in the context.xml
<Context>
...
<Resource name="jdbc/EmployeeDB" auth="Container"
type="javax.sql.DataSource"
description="Employees Database for HR Applications"/>
</Context>
Use Contexts
You can configure named values that will be made visible to the web application as environment entry resources, by nesting entries inside this element. For example, you can create an environment entry like this: (Source here). This can be set as context parameters or environment entries. They are equivalent to the entries made in a web.xml or a properties file except that they are available from the server's context.
Use database configurations and load those configuration at ServletContextListener
Another approach which I tend to follow is to create a relational schema of properties in a database. Instead of loading the properties file during server startup, load the properties from the database during start up.
public class ContextInitialize implements ServletContextListener {
private static Properties props;
public void contextInitialized(ServletContextEvent servletContextEvent) {
// connect to DB
// Load all the key values pairs as required
//put this into a Properties object, or create a hashtable, hashmap ..
}
//Getter
public String getProperty(String key){
// get value of key
}
//Setter
public void setProperty(String key, String value){
// set value to a key
}
}
Note: above is just an example.
Use environment variables or classpath variables
Use classpath / path variables in Environment variables and use System.getenv() in your java code to get these values as necessary.
We normally put our web app properties files in the Tomcat home folder. POJOS look on the launch folder. There will be other standard locations for other web servers.
final String tomcatHome = System.getProperty("catalina.home");
if (tomcatHome == null) {
// POJOs look in "."
searchPaths.add(".");
} else {
searchPaths.add(tomcatHome);
webApp = true;
}
An strategy is to pack all the properties and configuration files in an external jar and make this jar a dependency for your application(s): war, ear, etc. Then, you can deploy this jar in a common folder where the application server will load it and make it available for all the applications deployed there. This means that you will deploy the jar with the values for each environment once (or every time you need to change it, but its changes must be slow compared to the changes made to your main artifacts) and you can deploy and redeploy your war or any other project in your application server without problems.
In case of Tomcat, you may deploy this jar inside %CATALINA_HOME%/lib as explained in Tomcat Tutorial. Class Loader Definitions
To consume (read) these files in my application, I just load them like any other resource in my application.
Two strategies I've used:
JVM Parameters -- Custom JVM parameters can be set by the container at startup. This can get a bit verbose though if you have a lot of settings.
Configuration Files -- These can be read by the application. Either the location is hardcoded, put inside the container path, or to get the best of both worlds, specify the location via a JVM parameter.
Related
We build a webapp using ServletAPI 3 in combination with Tomcat 7 on RHEL.
I try to set a context specific init parameter [getServletConfig().getInitParameter("myinit");] via any of
${CATALINA_HOME}/server.xml (no conf-directory in between but obviuosly the same)
{engine}/{host}/{app}.xml
and to provide some meaningfull default ressource values via webapps war file content "META-INF/context.xml" in parallel.
But as soon as I define a context definition in the XMLs the defined DB connection we provide by context.xml within the war is ignored.
We build the webapp with ant as a single {app}.war file.
Obviously I don't provide the right settings but I don't understand how to do that without moving the db connection settings from META-INF/cotext.xml to the containers context definition (we don't want to do that - though this may obviously be a viable alternative).
Is it possible at all? If so: How? Is there an alternative option to do something similar?
Thanks a lot in advance!
I have a config.properties file which contains configurable properties e.g. database connection details in a webapp deployed on tomcat. e.g.
local.driver: com.mysql.jdbc.Driver
local.username:myuser
local.password:mypass
dev.driver: com.mysql.jdbc.Driver
dev.username:mydevuser
dev.password:mydevpass
I can retrieve the values from config.properties using spring Environment object or #Value.
My question is how do you make Spring's environment object pick local properties when running on local and dev properties when running on dev? Also it doesn't sound right to save sensitive data e.g. production database connection
details in properties file which will float around in code base. So how do you add production detail when in production environment? Ideally I would want to change them as and when I like and not have to redeploy the app. Am I going the right direction?
Note - All the answers I have seen on SO discuss changing these properties within java code. I don't want to do that I want to be able to configure these values independent of the application code.
Thanks
You can have a look at spring profiles to load a specific file for a specific environment.
Alternatively, you can also parameterize the file from where the properties are loaded in the application context using a JNDI property or an environment property set in the container.
Example:
<context:property-placeholder ignore-unresolvable="true" location="${env.config.file:classpath*:META-INF/spring/profiles/dev/dev.properties}" />
The env.config.file can be set at the container level (say Tomcat) using -Denv.config.file= when starting it. By doing this, Spring automagically finds the property in the system props and replaces it. If you don't set it explicitly (for example, in dev where you might use some other container, such as jetty), it would use the given default value (in this example, dev.properties).
By putting the properties files outside the war / ear, they can be changed at will, and only the context needs to be restarted. Alternatively, you could look into re-loadable property placeholders. This also helps if you don't want passwords stored in the war in clear.
For encrypting information in the property files, if you're using Spring 3, you can also check: http://www.jasypt.org/spring3.html.
for picking env specific values you have couple of options
If you can create multiple properties file based on env then you can use Spring profile feature (i.e spring.profiles.active), this will allow to control properties file to loaded via JVM parameter.
If you still want to keep all the stuff in single fle then you can override PropertyPlaceholderConfigurer to take env details from JVM parameter or default to some value
On security question , one the approach is to store encrypted password in prop file.
I want to be able to deploy my app using ANT to Tomcat.
I don't want the process to be any different for dev and prod. However the two use different databases i.e. myapp and myapp-dev
How can I make this happen? Can I store a variable in the different tomcat containers and make the application call the name of the database from Tomcat.
Or if what I am asking is ridiculous what is the generally accepted way to achieve deploying to dev and prod with the same process.
The generic way is to put the configuration string in a JNDI entry.
If JNDI is not a possible solution, then a property file in the right location (so it shows up in the classpath of the WAR files) is also useful, but needs careful documentation.
Have you considered letting the web container manage the database connection pool, so you only need a single one pr container, which then can be retrieved through JNDI?
In development I use jetty as the servlet container. I have the following development configuration:
master project which has wabapp directory
derived project which overrides some of the files in webapp directory
The master project webapp can be started in development mode thanks to providing appropriate WebAppContext to jetty.
Now I want to start derived project analogously, assuming that when request is made, there is an attempt to:
get resource from webapp directory of derived project
if it does not exists, get it from webapp directory of master project
I know that it is possible to override WebAppContext#getResource() method, however some libraries we use in the project seem to perform IO operations on wabapp directory on their own. For example by calling ServletContext#getRealPath("/"), and then reading files without use of ServletContext#getResource() method. The problem could be solved on lower level by some virtual file system on top of File, however it does not seem to be supported in JDK 1.6, any suggestions?
It seems that using something like ResourceCollection is sufficient:
http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/util/resource/ResourceCollection.html
Unfortunately the GWT's DevMode which I use is based on jetty 6, where ResourceCollection is unavailable. I extended the Resource class myself, and together with own GWT JettyLauncher, and thanks to small trick with setting resourceBase on DefaultServlet via reflection, I was able to serve webapp from two directories simultaneously.
protected void doStart() throws Exception {
setClassLoader(new LauncherWebAppClassLoader());
super.doStart();
ServletHolder holder = getServletHandler().getServlet("default");
Servlet servlet = holder.getServlet();
Field field = servlet.getClass().getDeclaredField("_resourceBase");
field.setAccessible(true);
field.set(servlet, combinedResourceBase);
}
Part of my webapp involves uploading image files. On the production server, the files will need to be written to /somepath_on_production_server/images. For local development, I want to write the files to /some_different_path/images.
What's the best way to handle these configuration differences?
One important requirement is this: I don't want to have to mess with the production server at all, I just want to be able to deploy a war file and have it work. So I don't want to use any technique which will require me to mess with the environment variables/classpath/etc. on the production machine. I'm fine with setting those on my local machine though.
I'm imaginine two possible general approaches:
loading a special "dev" configuration file at runtime if certain conditions are met (environment variable/classpath/etc)
flipping a switch during the build process (maven profiles maybe?)
Simple things like a String can be declared as environment entries in the web.xml and obtained via JNDI. Below, an example with an env-entry named "imagePath".
<env-entry>
<env-entry-name>imagePath</env-entry-name>
<env-entry-value>/somepath_on_production_server/images</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
To access the properties from your Java code, do a JNDI lookup:
// Get a handle to the JNDI environment naming context
Context env = (Context)new InitialContext().lookup("java:comp/env");
// Get a single value
String imagePath = (String)env.lookup("imagePath");
This is typically done in an old fashioned ServiceLocator where you would cache the value for a given key.
Another option would be to use a properties files.
And the maven way to deal with multiple environments typically involves profiles and filtering (either of a properties file or even the web.xml).
Resources
Introduction to Build Profiles
9.3. Resource Filtering
Have defaults in your WAR file corresponding to the production setting, but allow them to be overriden externally e.g. through system properties or JNDI.
String uploadLocation = System.getProperty("upload.location", "c:/dev");
(untested)
Using a properties file isn't too difficult and is a little more readable the web.xml
InputStream ldapConfig = getClass().getResourceAsStream(
"/ldap-jndi.properties");
Properties env = new Properties();
try {
env.load(ldapConfig);
} finally {
if (ldapConfig != null) {
ldapConfig.close();
}
}