I am developing a logging framework using Log4j. I am not able to figure out how to maintain separate log files for different environment, i.e., development, testing, staging and production.
Firstly you'll need a different copy of your log4j.xml for each environment.
Lets call it log4j-dev.xml, log4j-test.xml, log4j-stage.xml and log4j-prod.xml each having their own settings like log file name and log levels.
You then pass in the corresponding file at the the server startup as a system property like below -
-Dlog4j.configuration=log4j-dev.xml
This URL has the example on how to pass this for Tomcat. The concept is the same for whichever server you are deploying on.
On Windows, I have used "set CATALINA_OPTS=-Dlog4j.configurationFile=log4j2-dev.xml" instead of log4j.configuration
Related
I have EJBs deployed on several different servers, for different environments. I have many projects that use these EJBs. I usually just run my projects against the DEV server EJBs, but sometimes I need to run against the TEST or PROD environment EJBs. This necessitates having to comment out all of the DEV nodes in my jboss-client-ejb.properties file and uncomment all of the TEST nodes. But then if I forget to change them back, I may mess up some data if I run it later. What I would like to do is create a different runtime configuration for each environment, and have each runtime config use a different version of the jboss-client-ejb.properties. Is there a way to do this? If so how? I have looked at all of properties of a run configuration, and don't see anything helpful.
In eclipse preferences search for string variable substitution. Here create variables that point to multiple config files for each of your environments. Then create multiple run configurations and for each one (like dev or prod) add a program argument that points to your string variable defined in your preferences like this -DmyconfigFile={$MyDevPropertiesFilePath}, or you could hard code the config path and have multiple runtime configurations that use different config files. Key point here is create multiple runtime launch configurations for each environment and add the properties for each environment that point to the config file respective to each environment. This way you can easily select the launch menu and decide to run "dev" "prod" or whatever you name your multiple configurations. Trying to do this with one runtime configuration will cause pain as you say, because it is easy to forget to revert or change the config file you want to to use. Hope that helps. Also if you create a new workspace you can export your runtime configurations using the export wizard which is also helpful for passing on to other developers or putting in source control.
P.S Looking more at your question you wan to pass in the config file path as a program argument, you are correct there are no specific options for setting this file path. Using program arguments with multiple launch configurations.
What is the idiomatic way to store and retrieve configuration settings in a deployed Clojure Luminus app?
In the Luminus template on which I base my app, the profiles.clj file is used to store the database connection string. However, when I compile the app using lein uberjar the profiles.clj settings do not seem to be included in the compiled file. And I would nevertheless not want the database connection to be stored in the compiled file but rather reside in a configuration file on the production server.
Optimally, local configurations should be stored and retrieved in the same manner regardless of whether the app is run in development or production mode. But I can't figure out how to do it.
You may be interested in using the environ library. From their README:
Let's say you have an application that requires a database connection. Often you'll need three different databases, one for development, one for testing, and one for production.
Lets pull the database connection details from the key :database-url on the environ.core/env map.
(require '[environ.core :refer [env]])
(def database-url
(env :database-url))
The value of this key can be set in several different ways. The most common way during development is to use a local profiles.clj file in your project directory. This file contained a map that is merged with the standard project.clj file, but can be kept out of version control and reserved for local development options.
{:dev {:env {:database-url "jdbc:postgresql://localhost/dev"}}
:test {:env {:database-url "jdbc:postgresql://localhost/test"}}}
The http://www.luminusweb.net/docs/environment.md#edn_based_configuration page helped me.
java -Dconf=config.edn -jar app.jar will start a compiled app with the configurations stored in config.edn.
For my Play 2.2/Scala application (built with SBT), I would like to deploy different configuration files depending on the environment I'm deploying to (e.g. to couple a deployment with a particular database server). How does one create different variants of the application's configuration file (conf/application.conf) for different deployment targets? Hopefully variants can be generated from a base version?
What I'm used to from .NET is to have a base configuration file (Web.config), which undergoes a certain transformation depending on the profile one is deploying (e.g. Production). Does one use a similar technique in the Play/Scala world?
Alternative configuration files are covered in Play's documentation quite well in section Specifying alternative configuration file.
In short - in application.conf you place default configuration of your app, and additionally you need to create additional files for you environment(s) ie. life.conf, dev.conf etc. In these files you first need to include application.conf (which will read whole default configuration) and next just overwrite only parts which have to be changed - ie. DB credentials, it could be dev.conf:
include "application.conf"
db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:mem:alternative-database-for-dev-testing"
db.default.user=developer
db.default.password="developerpass"
So finally you start your application (after dist) as
./start -Dconfig.resource=dev.conf
or with the Play console
play -Dconfig.resource=dev.conf run
Several tips:
It's good idea to do not place your 'life' DB credentials in default application.conf file, if some dev will forget to include his dev.conf he won't damage the production DB, instead you should put it in prod.conf.
Also these additional configs shouldn't be placed in any VCS (ie. git) repository - creating them directly on target machine (and ignoring in repository) give you sure, that people who shouldn't know the life database credentials won't see it.
It's also possible to use remote alternative config file, which can be useful ie. when you deploying several instances of the same app ie. on several hosts in the cloud.
Each dev can has own config file ie dev_aknuds1.conf, dev_biesior.conf etc, so you can ignore them with one pattern dev_*.conf in repo.
Finally you can just create a shell script (unix) or bat file (Windows) to start using choosen config file like start_dev.sh, run_dev.sh etc. so you won't need to write -Dconfig.resource=... each time
I have a transform for my web.config that currently works if I publish to Azure, but it's not working locally when I build/run. How can I go about "Publishing" locally so the Local transformations are applied to my web.config on my dev box?
Currently I right-click > publish to Azure, do I need to create a new publish profile for my local box? Is there any way to get the transforms to work on Build instead?
It depends on which dev server you are using. As #Citronas said on this answer:
It depends on how you debug. If you are using Cassini, afaik your
web.config contents will be read regardless of the selected solution
configuration (e.g. Debug or Release).
If you are debugging with your
local IIS, it depends on what you have set the path in the IIS to. If
you have set it to your source code directory, you need to write your
local settings into your web.config. If you publish your code into a
local directory and set the IIS path accordingly, you can use
web.config transforms. (You said, that your web.config transforms are
working)
You do not need to publish locally (even though you can do that, publish to local IIS then attach the debugger to the worker process of the application pool) since it is annoying. The easiest way is to simple have your debug settings in the web.config file and then apply transforms for your "publishable" environments.
In short: do not use transforms for debug, only for publishing. Use the regular web.config to debug.
I'm using NAnt to build an ASP.NET MVC project.
The NAnt script then creates a zip package, containing a deploy script and all the necessary files.
The deploy script backs up the current running website, sets up the newer version of the website and updates the DB.
This works fine for a single environment.
However, we're asked more and more to set up a Staging/Acceptance environment next to the production. These environments, of course, differ in file structure, DB server, config settings etc.
How can I best handle this in the deploy scripts? I don't want to create separate variables for each environment, distinguishable by name only.
Providing defaults and providing the variables in separate files seems more logical.
Does anyone have practical experiences with this?
Store the things that you think are likely to change between environments in config files.
Visual Studio can do the heavy lifting here if you like; you can create settings and specify default values from the Settings tab of a Visual Studio project's properties.
This will create the config file for you and provide strongly-typed access through Properties.Settings.Default.
As for handling multiple environments through your build, I've seen some people recommend maintaining multiple copies of the config files - one for each environment for example - and others recommend using nant to modify the config files during the build or deployment phase. You can use a property passed to nant on the command line (for example) to select which environment you are building (or deploying, depending on how you're doing it).
I don't recommend either of these approaches because:
They both require changes to your build to support new environments.
If you change a setting in a deployed environment and forget to update the build then the next deployment will reset the change (somewhat defeating the point of config settings).
If someone creates a new environment (lets say they want to explore issues arising from upgrading to a new version of SQL Server for example) and doesn't fancy creating all new config files in the build system, they might decide to just use an existing environment's settings. Let's say they choose to deploy using the live settings and forget to change something afterwards. Your new 'test' environment could now be pointing to live kit.
I create a copy of each config file (called web.config.example, for example) and comment out the settings within them (unless they have meaningful defaults). I check these in and have those deployed instead of the real web.config (that is, web.config is NOT deployed automatically. web.config.example is deployed as web.config.example.
The admin of the new environment will have to copy and rename the file to web.config and provide meaningful values). I also put all the calls to the settings behind my own wrapper class - if a mandatory setting is missing I throw an exception.
The build and my environments no longer depend on each other - one build can be deployed to any environment.
If a setting is missing (a new environment or a new setting in an existing environment) then you get a nice clear exception raised to tell the admin what to do.
Existing settings are not altered after an upgrade because only the .example files were updated. It's an admin task to compare the current settings with the latest example and revise if necessary.
To configure the deployment, you could put all the environmental settings (install paths, etc) into nant properties and move them into a separate file (settings.build for example) then use the nant include task to include that file at the top of your deployment file (deploy.build for example). You can then deploy a new version of deploy.build without overwriting your config changes as they are in settings.build. If a new property is introduced into deploy.build nant will fail with a nice message to tell you that you haven't set that property.