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.
Related
I'm trying to add authorization to several microservices. Given all the services share similar authorization process, I want to extract the logic to a shared library.
I managed to create library, but I realise all the configurations need to be set in the application.yml file in the microservice which calls the library. I don't want to expose some of the configurations at service layer though.
After some searches, I found I could set #PropertySource("library.properties") in my library's configuration class to force reading properties from the specified .properties file within the library.
The problem now is I want to set different values for different environments, e.g. authorization URL for test and production would be different. How can I configure the file so that the configuration class would read same property value based on active profile (e.g. environment = test/staging/production)?
You can have multiple property files such as "application-environment.yml” in your resource folder. Spring framework picks the right one based on the active profile.
For example, if you define a “staging” environment and have a staging profile and then your property file should be named as application-staging.yml.
Currently, we store our application's environment properties in a .properties file in the WEB-INF. We want to move them to a database table. But we still want to specify the jndi name, and when running in our test environment locally, we want to be able to override certain properties just for our workspace for test and development.
Apache commons' DatabaseConfigurator seemed nice, but wouldn't play nice with the jndi name being defined as a property in the file. Nothing I did to ask it to look at the property file first worked.
I decided to subclass apache commons' AbstractConfiguration to try to create a single configurator that would check the file and database as I wished, but again, it didn't really work. Spring wants that jndi name absolutely first, probably because the data source has to be passed into the configurator as a parameter.
How can I get what I am after here? Mostly properties in the database, but those that are in the file override them. And jndi name for the datasource should not have to be hardcoded in the spring config.
Why don't you write a ApplicationContext listener that will read the configuration from your DB and inject them in the JNDI? Then you can override the configuration in the JNDI with a context.xml file that will be placed in the src/local/webapp/META-INF/.
This is how we get this working in our webapp.
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.
I am developing a Struts 2 web application, all the constant values and hardcoded values are moved to a properties file along with those, the constants which are specific to environment like Data source name, some of the server connection urls and few user ids are also placed in the properties file.
Initially I placed the properties file in the class path and accessed using resource bundle as below
ResourceBundle RESOURCE_BUNDLE = ResourceBundle.getBundle("config\appProps");
Problem with that is Because of those environment specific constants for ever environment(DEV / UAT / PROD) a separate war needs to be generated by changing the properties file environment specific constants value, to avoid that I am using below process
I kept the properties file absolute path in the context parameter of the web.xml and get the path from the context and reading the properties file as below
Properties prop = new Properties();
prop.load(new FileInputStream("<<file system absolute path from context param>>"));
This eliminated the process of generating different war for each environment as path on the server can be maintained same, but I came to know that security wise we should not use absolute paths like that which might expose the server file system details
Please let me know What is the correct way of loading the properties file in a web application by considering security as well as eliminating generation of different war files for each environment.
Thanks.
You could maybe hoist the whole properties object into JNDI, that would fix it, but implementations may be server specific. And now you've got a new problem; make sure that the properties are loaded before you read them.
I have several Spring based apps - web, web services
For my web services project, in my ws-config.xml file, I specify the location of the wsdl. This has been set to localhost in the past, but I now need to have this as a configurable value in a properties file if I can.
<ws:dynamic-wsdl id="ServiceDefinition"
portTypeName="Test" locationUri="http://localhost/Test/webservice">
<ws:xsd location="/WEB-INF/schemas/my-test.xsd" />
</ws:dynamic-wsdl>
I need to be able to reference the locationUri as a property, but I dont know how to do it?
Can anyone help?
Check out the PropertyPlaceHolderConfigurer. You can use this to specify properties in your Spring configs, and specify which properties sources to populate this property from. You can specify a hierarchy of sources, such that (say) you have a file of default properties, and then some overridden values in a per-user config.
Here's a trivial example.