I don't believe attachments don't come through the mailing list.

In our environment we use a repository (a CMS or source control system) to 
manage the files but they are read from the file system by the applications. 
Since the file systems are blocked by firewalls when going from dev to QA to 
prod, etc. it isn't really possible to share a single copy of the file anyway. 
However, commons configuration supports a number of features that can help.

A) You can use tiering. With DefaultConfigurationBuilder one of the tiers can 
contain your environment specific values.
B) You can use system properties. With DefaultConfigurationBuilder you can 
cause the system properties to be loaded. Then in your configurations just 
reference the properties as $(sys:property}. 

However, in our environment we have found that one of the best ways to 
accomplish what you are showing in your example below is the use the same url 
in each environment. Change your DNS servers to resolve the name to the correct 
location instead.

Ralph


On Apr 25, 2010, at 2:07 PM, Santhosh Kumar wrote:

> Hi Oliver,
> 
> Thanks for the reply. While that solution works but user would need to 
> maintain multiple properties files at the risk of not keeping all of them in 
> sync. Also that solution doesn't allow to have a common properties along-with 
> environment specific properties elegantly (but is possible using include 
> statement to a common properties).
> 
> My thought was to suffix the property with an environment specific string. At 
> runtime specify which environment server is running in (Let's say 
> "server.env" system variable). Depending of the value of this system 
> property, this Configuration object would return the environment specific 
> value (if defined, else the default value).
> 
> For example, if we want to have database related properties, here is what it 
> would look like.
> 
> databaseURL=jdbc:oracle:dev-url
> databaseURL.qa=jdbc:oracle:qa-url
> databaseURL.stg = jdbc:oracle:stg-url
> databaseURL.prd = jdbc:oracle:prd-url
> 
> databaseUserName=testUpdatedProperty
> 
> databasePassword=defaultpassword
> databasePassword.prd = passwordprd
> 
> When application requests for a property (let's say databaseURL), this 
> configuration object would first suffix that with specified environment 
> string (using server.env system parameter) and try to get the value for 
> "<key>.<environment string>". If The value present, it would return the 
> value. If value not defined, then it would look up the value for just "<key>".
> 
> See the attached sample code I have written and been using it successfully in 
> our projects.
> 
> Thanks,
> Santhosh.
> 
> -----Original Message-----
> From: Oliver Heger [mailto:oliver.he...@oliver-heger.de] 
> Sent: Saturday, April 24, 2010 12:18 AM
> To: Commons Developers List
> Subject: Re: [Configuration] Environment Awareness in Configuration
> 
> Am 23.04.2010 20:36, schrieb Santhosh Kumar:
>> It is a very common requirement that some configuration value changes across 
>> environments (dev/qa/stg/prd etc). I went through the documentation but 
>> didn't find any feature to do this in the Configuration (please correct me 
>> if you know a way to do this).
>> 
>> If such feature doesn't already there, I was hoping something like 
>> EnvironmentAwareConfiguration can add such feature based on the environment 
>> and server id (for usecases where each server in the production cluster 
>> needs to get different property value).
>> 
>> Please let me know what you think. If this is something adds value (which I 
>> truly believe it will), I will post a detailed information.
>> 
>> Thanks,
>> Santhosh.
>> 
> 
> One way to achieve this would be to use DefaultConfigurationBuilder and 
> the interpolation facilities supported by all configuration 
> implementations. For instance, you can have the following definition 
> file for DefaultConfigurationBuilder:
> 
> <configuration>
>   <properties fileName="${env:STAGE}/config.properties"/>
> </configuration>
> 
> Here with ${env:STAGE} the OS environment variable STAGE is referenced, 
> and the properties file is load from a subdirectory whose name matches 
> the value of the variable. The environment variable could have different 
> values depending on the specific server environment and thus different 
> configuration files would be loaded.
> 
> Note however, that interpolation of environment variables is available 
> in Commons Configuration 1.7 only which has not yet been released.
> 
> Would this approach work for you?
> 
> Oliver
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to