config.yml override at runtime and maven resource filtering conflicting with Shade plugin

[Adam Parrish]

Hi all:

I am working on a small project with Dropwizard and want to be able to set my selected environment for my base URL when I start the server on different environments. I was thinking of using something like this on the command line when I fire up the jar to set the property for selected environment:

-Ddw.urlConfiguration.selectedEnvironment="development"

Clearly this is wrong I am just unsure of how to do it. I have a UrlConfiguration object that has a selectedEnvironment property on the class. How do I populate that property with a value at runtime with a -D parameter?

Alternatively I was going to use Maven resource filtering to populate it from a profile and just build 3 jars, one for each environment. That isn't working because the Maven Shade plugin is somehow ignoring the filtered resource in the target/classes directory when it creates the Uber-jar. Is there a solution for that either as I am worried that I'll need resource filtering for another purpose later.

Thanks guys,

Adam 

[Nick Telford]

Why not just use a different config file for each environment?

[Adam Parrish]

I would prefer not to manage all that identical configuration. I want to just change one variable and have it update all the other information so I can manage it in github. Kind of trying to focus on DRY.

[Nick Telford]

I'd recommend maintaining a single "template" config file in your source tree and use a config management system (e.g. Chef or Puppet) to handle the differences between environments.

Shading your config and rolling a JAR for each environment isn't much different from simply hard-coding all the values in the source. The advantage of having a config file is that you can alter the behaviour of your application without having to modify the source, re-compile and re-deploy. Shading in your config eliminates this advantage entirely.

A quick and simple solution would be to have the values that you want to repeat across all environments as defaults in your config classes. That way your config file will only need to specify the settings that you wish to vary across each environment.

[Tatu Saloranta]

On Thu, Aug 9, 2012 at 7:50 AM, Adam Parrish <wapa...@gmail.com> wrote:
> Hi all:
>
> I am working on a small project with Dropwizard and want to be able to set
> my selected environment for my base URL when I start the server on different
> environments. I was thinking of using something like this on the command
> line when I fire up the jar to set the property for selected environment:
>
> -Ddw.urlConfiguration.selectedEnvironment="development"
>
> Clearly this is wrong I am just unsure of how to do it. I have a
> UrlConfiguration object that has a selectedEnvironment property on the
> class. How do I populate that property with a value at runtime with a -D
> parameter?

What exactly are you trying to do? As you mentioned, you can extend
existing configuration POJOs (including sub-classing, although this
requires sub-classing classes of the whole POJO chain).
And since Configuration and other classes are just POJOs, you can
override any behavior; including adding getters/setters to mask fields
(i.e. when reading yaml/json, matching setter is called, in which you
can take action you want).
This also means that you can change the default values, usually from
constructor.

And even more than that, code that uses this configuration can be
overridden. It's all pretty basic code for things like setting up
Jersey, Jetty.

I have only done basic overrides, such as ability to programmatically
override port number for unit/func tests. But tests do not use any
external configuration, instances of Configuration are created as
regular Java objects.

-+ Tatu +-

[Adam Parrish]

Gents:

I used to use spring PropertyPlaceHolderConfigurer in other projects. When I did that I would use a -DpropertyOverrideFile=/location/to/override.properties. I more or less just want to not have to setup Chef and Puppet to manage other environments but use a -DtargetSystem=prod or -DtargetSystem=development to have the configuration load a set of URL's for services or base urls from one configuration file in my system. I am aware that the configuration is externalized but I would rather just have to tweak one variable to have it setup all of the values for an environment than to keep a configuration file on each machine I want to deploy to. 

Anyways I appreciate the insight on alternative ways to do it and have debugged the CLI Parser to see that since my -DtargetSystem parameter isn't in the options that it throws an error. Given both Tatu and Nick haven't worked around such a thing it appears the only way to do this is with a set of extra config files. I can cope with it just was hoping there was a way to pass in a -Dvalue=something and write some code to do a System.getProperty("value") so I can trigger some behavior during the initialization before all the services fire up. 

If something comes to mind I'd love to hear it otherwise I'll just work around it by duplicating the files. 

-Adam