[RFE] Load config file from fat-jar

[Piero Ottuzzi]

Hi,

   I'm experimenting with dropwizard and when I followed the tutorial it was not clear to me from where the config file would have been loaded from: as a guess I expected it was loaded from the fat-jar and so I put it in the src\main\resources as per maven convention but this did not worked.

Is it possible to modify dropwizard to load config file from the fat-jar?

Many thanks

Bye

Piero

[Nick Telford]

When you run your application, you specify the path to your config file, so it can be anywhere on the host system:

$ java -jar application.jar server /path/to/config.yaml

Regards,

Nick Telford

[Piero Ottuzzi]

On Monday, November 26, 2012 11:59:52 AM UTC+1, Nick Telford wrote:

When you run your application, you specify the path to your config file, so it can be anywhere on the host system:

$ java -jar application.jar server /path/to/config.yaml

Regards,

Nick Telford

Hi,

   I was asking if it is possible to modify Dropwizard to look for config file also inside the fat-jar.

Sorry if I was not clear.

Thanks

Bye

Piero

[Nick Telford]

The configuration file is loaded using java.io.File, so no. You'd need to patch Dropwizard to do that.

Configuration is a runtime concern; why would you want to bake it in to your JAR? If you're looking to bake in a "default" config that can be overridden, you should just set defaults in your Configuration classes themselves.

[Piero Ottuzzi]

On Monday, November 26, 2012 4:44:59 PM UTC+1, Nick Telford wrote:

The configuration file is loaded using java.io.File, so no. You'd need to patch Dropwizard to do that.

Configuration is a runtime concern; why would you want to bake it in to your JAR? If you're looking to bake in a "default" config that can be overridden, you should just set defaults in your Configuration classes themselves.

Hi,

   thanks for answering! I was thinking about embedding configuration file(s) in the fat-jar to simplify product deployment.

With config embedded you have:

1) only 1 file to copy on deployment servers (the fat-jar)

2) config files in same project/versioning of the whole project

3) config file(s) always aligned with the jar requirements as per point 2)

4) you can embed more config files (devel/QA/prod) and select the right one at runtime.

These are the points I see to change how things works now: it it even possible to give priority outside the jar (as it is now) and if not found go and look in the classpath.

Just an idea

Thanks

Bye

Piero

P.S.: I really would like to provide a patch but actually I'm to much a newbie in dropwizard to be useful...

[Ryan Kennedy]

On the flip side you can't change anything without making, testing and deploying a new build. Hopefully you never deploy a build with any typos in the config or it may take some time to recover. 

Ryan

[Coda Hale]

It's not currently possible, nor do I want it to be.

The fat JAR is environment-agnostic: you can run it locally, in staging, in a QA environment, or in production. The configuration file is environment-specific.

--
Coda Hale
http://codahale.com

[Mårten Gustafson]

On Mon, Nov 26, 2012 at 5:02 PM, Piero Ottuzzi <ott...@gmail.com> wrote:
>
> With config embedded you have:
> 1) only 1 file to copy on deployment servers (the fat-jar)
> 2) config files in same project/versioning of the whole project
> 3) config file(s) always aligned with the jar requirements as per point 2)
> 4) you can embed more config files (devel/QA/prod) and select the right one
> at runtime.

Aside from the points made by Ryan and Coda, which I personally agree
with, you might also be able do your configuration programatically by
simply not creating any configuration YAML files at all - but rather
write a DW configuration class that provides defaults for all values
and/or just providers getters for configuration values and in those
getters apply all the black magic you would need to determine whether
or not to return a dev, qa or production value.

On a related note: http://www.12factor.net/config



/mårten.

[Eric Tschetter]

Fwiw, the characterization of "loading from the fat-jar" is probably not the best way to phrase it, but loading resources off the classpath doesn't necessarily mean that you are mixing compile/dev-time concerns with runtime concerns.  It is very possible to write a file to disk in some path and just include that directory on the classpath at runtime.  Hadoop does this (for better or worse).

At the same time, the load-as-a-resource method generally means that you are hard-coding the name of the config file (given that you can only provide directories to the classpath) and it means that you aren't going to run with the "-jar" parameter because you need to specify more stuff on your classpath.

Not that I think it's bad to take it as an argument either, I'm just trying to say that it's much more a question of preference and convention than of actual functionality.  And, there's nothing wrong with preference and convention ;).  Fwiw, if I had the option of just adjusting my run scripts to work with passing the parameter as an argument or adjusting the DW code to handle loading a resource instead of a file, I'd choose to adjust my run scripts...

--Eric

[Piero Ottuzzi]

Hi,

   sorry to insist but English is not my mother language and it looks like I was not clear.

I completely agree with you that fat-jar IS environment agnostic.

I completely agree that configuration is a runtime concern.

I really like the fact that I can use and deploy fat-jar setting configuration file at command line and I'm not asking to change that: I'm simply asking if it is possible to look for the configuration file stated in command line also in the fat-jar. Not only in fat-jar but also in fat-jar. 

So the command-line would be kept the same:

$ java -jar application.jar server /path/to/config.yaml

but /path/to will be searched even in classpath if !file.exists().

Thanks for your patience.

Bye

Piero

[Coda Hale]

I understand what you're asking for and I'm not going to do it.

If you'd like a more in-depth explanation of why, I'd suggest searching for some of the previous conversations on this mailing list about this subject.

---
Coda Hale
http://codahale.com

[Wade Chandler]

I have is a micro-service strategy. I would like to be able to depend on my various services "service" artifact in the "test only" dependencies of a dependent service. Then, using DropwizardAppRule for JUnit, I would like to be able to have a static variable in that service package some where which could be used like so:

new DropwizardAppRule(someDependencyApplicationClass,SomeServiceConstantsClass.TEST_CONFIG, overrideSomeConfig1, overrideSomeConfig2)

The test config file, which makes sense for me to be controlled in the other project which contains SomeServiceConstantsClass would then be one which configures that service to run standalone for the specific purpose of dependents tests to work without having to be on a VPN or a larger network context since these tests are not "performance" tests. I feel this way because I don't want all my other services to know about all the configuration changes which might happen for that dependency at the service layer and its config. Any transitive dependencies could then be configured similarly in any cascading configuration files which any other service may depend if they are all configured in the context of testing. This feels like a clean approach to me as the specific services and their developers would know what is best in that context, and too, some of those other service dependencies become esoteric above their configuration and development levels.

If there are some other thoughts on this topic, that would be welcome too. Maybe some clean approaches to the problem of needing to be able to run a service simply as a test dependency and have its dependencies satisfied in some way unknown to the caller. I don't see anything about this in the docs or the project pages. One way is to have a utility which will copy a file from a classpath resource to the build directory, but that seems overkill and overhead.

Thanks,

Wade