I have a Play 2 application that uses some external Java libraries. Some of these (e.g. the Paypal merchant sdk) depend on having a properties file for configuration (e.g. sdk_config.properties) which I have put into the conf directory.
When deploying this application to a different environment using play dist is there a sensible way to swap out properties files for each environment? For the main configuration in application.conf this is straightforward e.g. start -Dconfig.resource=prod.conf, but I am not sure how to do something similar for the properties files.
The support for specifying config.resource (and a lot of other nice stuff) is built into the typesafe config lib that comes with play. Other third party libs that depend on properties files on the classpath may or may not accept something like that, so if you are lucky then there is a lib specific way to point it to a separate config file.
If they do not then the only option is to somehow provide a different file on the classpath for the different environments. This could basically be done in two ways:
A. To not ship the file with the artifact and instead provide it per environment and add that on the classpath when starting play.
B. To create different artifacts for the different configurations, this would require you to customize dist to create one artifact per distinct env.
I would go for A since it allows there to be one artifact that can be run anywhere, but it might add some annoyances to running the app in a dev env etc.
Related
I have created a simple application with DockerPlugin in sbt file and it uses my default application.conf file to load resources. But now, I will need to change this configurations depend on environment (other for dev, other one for prod). Is it possible to tell docker which configuration file should be used? I tried to separate application.conf data into prod and dev and load files in case of given environment in path, but I don't think so it is good solution.
I have a Maven project written in Scala and deployed as a .jar. The project has the typical structure:
project-root
|__src
|__main
| |__scala
| |__resources
|
|__test
|__scala
|__resources
I have many hardcoded values in the application that I'd like to extract to a configuration file.
I could just create a text config file anywhere, read it from the code and use the parameters, but I'm looking for a best practice/approach. I'd like to take this things into account:
Is there a way such that I can change config values and not have to rebuild the .jar? That would be very practical.
Where would be the best location for the file? E. g. create a project-root/src/config directory and put the file there?
Any remarkable reasons about choosing among different formats? I'd go with XML, but I've seen quite a bit of YAML and HOCON around...
If you want to be able to change configuration values without building the jar, you will want your config external to the artifact. There are ways to modify the contents of the built jar but I don't think that is what you are wanting to do. If you want to have config you can change on the fly, keep it out of your jar and reference it on the Classpath at runtime.
If you want to keep it on your artifact, and rebuild when you change values, keep the configuration file in src/main/resources. Maven will automatically package it into your jar for you at the root of the archive.
As for format, that's probably personal preference. Reading YAML usually requires another library such as snakeyml to parse effectively, so if you are trying to keep your library light on dependencies, maybe look at .config or .properties files instead. Otherwise, XML and YAML are always nice for complex configuration.
I come from the C# .NET world and as I build my Scala project I noticed how many different ways there are to do things in the open source community. Anyways in .Net C# project we have the Web.config or the App.config file which is very useful to specify app keys that are used globally and it is also helpful for transformation for different environments and such.
What would be the equivalent for a Scala SBT project? Do you know a place to store your connection strings and other app settings?
There is no universal configuration file name. The basic way is to use Properties, see e.g. how to read properties file in scala, and call the file your-application-name.properties. But there is a popular library called simply Config which I'd recommend; as https://github.com/typesafehub/config#standard-behavior says, its standard names for config files are
The convenience method ConfigFactory.load() loads the following (first-listed are higher priority):
system properties
application.conf (all resources on classpath with this name)
application.json (all resources on classpath with this name)
application.properties (all resources on classpath with this name)
reference.conf (all resources on classpath with this name)
The idea is that libraries and frameworks should ship with a reference.conf in their jar. Applications should provide an application.conf , or if they want to create multiple configurations in a single JVM, they could use ConfigFactory.load("myapp") to load their own myapp.conf . (Applications can provide a reference.conf also if they want, but you may not find it necessary to separate it from application.conf .)
As #ashalynd's answer says, in order for any such library to see your configuration files, they should go into src/{main,test}/resources.
I think you are talking about application.conf. It can be found in /src/main/resources or in /src/test/resources (affecting main and test settings, respectively). If application.conf is not present in /src/test/resources, the main application.conf will be used for the tests.
At my company, we use Weblogic (depending upon the installation anywhere between versions 6.1 to 11g).
Right now, we embed environment specific variables into our ears, jars, and wars. This even includes the weblogic.xml file where we have something like this:
<working-dir>/opt/bea/wl61/server/domains/deploy/prod3/temp/work</working-dir>
That means we have to rebuild the same jars, ears, and wars for each and every environment. And, if there's a change in the environment, we have to rebuild and redeploy the wars, ears, and jars. You can imagine the issues and problems we have with build and release management (which is my job).
At my last position, we used JBoss, and somehow were able to create generic and deployable ears. I would have Hudson build an ear that the developers could use for their testing. This same ear could then be passed to our QA team in their environment, to UAT, staging, and into production.
We could do this amazing feat because we configured JBoss to look for properties files OUTSIDE or the ear itself. There was a config directory that was a sibling to the deploy directory that contained any needed properties files. Is it possible to setup Weblogic to do the same thing?
We need a way to do this with minimal code changes. I've already examined the source, and we don't specify the directory name when we specify loading the values in the properties files. Therefore, we might be able to do this with some sort of CLASSPATH idea.
I understand that these properties must live somewhere, but I would prefer if it could be configured in the environment, and maybe done by having the path relative to the deploy directory. I want to use the same ear, jar, and war files no matter what system you are on: Windows PC desktop, Linux, Mac, or Solaris server.
The toughest issue will be our weblogic.xml embedded path. Can that path be relative to the deploy directory and not from the root of the system?
As I stated before, I'm the build manager, so as far as everyone is concerned, this is my headache, and not their problem. If deployments don't go well, the Finger 'o Blame can point directly at me.
In order to get this to done I have to be able to find a solution that's simple for us to implement. We can't rewrite everything and change everything around. Otherwise, I can't get the other teams to do this. After all, it's my issue and not theirs. We need something with minimal coding changes (preferably none) and minimal changes in our Weblogic setup. I want something that in Version 3.4 of our software, we do it the old fashion environment specific way, but in Version 3.5, we can deploy in an environmentally neutral way and do that with minimal changes in our deployment environment.
I can feel your pain - I went through the same process at a couple of companies. You have a couple of options that would be a significant improvement from your current setup:
1) Modify the CLASSPATH to use an external directory / properties file that overrides everything that is in the ear file. This is easy to implement but can get out of hand without the proper standards/governance.
2) Use deployment plans to define environment specific variables. However, deployment plans were not introduced until the WebLogic 9.2.
3) Roll all of your environment specific files in to its own jar. All environments would be pointing to the same file but it would be building out different contents based on your build process. Advantages - Single file that contains all the props, easy to move, etc. Disadvantages - Cannot change properties on the fly and force a reload from the JVM.
There may be other options based on the repository. IMHO, all of these work more or less the same - It's the process and enforcing it that prevents issues.
I have a Java web app that offloads some environment specific settings (Hibernate configurations, required directory paths, etc.) in a properties file that is ultimately packaged in the deployed WAR. If I wish to distribute this web app, what's the best way to handle the mangement of these settings? It's not feasible to ask the user to open up the WAR, update the properties file, repackage the WAR, and then deploy. I was thinking of either creating an installer (e.g. NSIS, WiX) that asks for the properties, writes them in the WAR, and then asks for the deployment location for the WAR. The other option is to have the properties file external to the WAR, and based on convention the web app will know where to read the file. What's the best practice in this case?
Some projects that require this sort of configuration, and face this issue, use the approach of building the projects (and the .war) on the server where it will be deployed.
So instead of:
Copy a pre-packaged .war file to a meaningful location
You get:
Check source code out of SCM (Subversion, CVS, etc.)
Configure to taste
Build the project (automated with Maven or Ant)
Deploy the project (also typically automated using Maven or Ant)
From here you can get fancy by checking each server's configuration files into SCM as well. This approach allows you to version & audit configuration changes.
I was also facing the same problem in the project. The developer before me had done crude fix for the solution which was adding all the required configuration in the hibernate.hbm.cfg.xml file and commenting them. The required configurations were uncommented as per the need. There is a better solution to problem however.
Use a configuration folder schema
Using configuration Parameter Reader
Use of ConfigurationReader component
Source : http://www.javaworld.com/javaworld/jw-11-2004/jw-1108-config.html