[2.0] config.file option doesn't seem to work

[Kenner Stross]

Per the instructions on launching Play in production mode:
https://github.com/playframework/Play20/wiki/ProductionStart, I am
starting my app as follows:

play "start -Dconfig.file=/Users/kenner/Documents/api/conf/prod.conf"

However, I can see based on what database is is accessing (play -
database [default] connected at jdbc:mysql://localhost:3306/titan_1_0)
that it has ignored my prod.conf file and is instead using the dev
default, which is application.conf.

I believe this problem has been reported before (http://
groups.google.com/group/play-framework/browse_thread/thread/
4a6c2afd82069b53/674695f388d315a4?hl=en&lnk=gst&q=2.0+dev
+prod#674695f388d315a4). Has anybody made any progress on this? Is
there a workaround? Are there other "best practices" for managing two
different configuration states -- one for dev and one for prod?

Thanks,
Kenner

[peter hausel]

Hi Kenner, I just pushed a fix for this. Thanks, Peter

[Ben McCann]

Thanks Peter =)

[Kenner Stross]

Thanks, Peter.

Just to clarify, though, it appears that this behavior of overriding
the configuration file is only available when we launch through the
"play" command. In other words, we can't specify a config file
override when launching via "./start". Is that correct? Based on my
limited testing so far, that appears to be the case.

If so, this would be most unfortunate, IMHO. The very slick feature of
being able to pull together a complete "dist" is wasted if we must
ALSO install Play onto every one of our production servers simply in
order to pass the correct configuration file. Ugghhh... I really hope
that's not the case, or if it is, if the Play team would reconsider.
To be ready for true commercial-scale, production deployments, the
dist that Play generates should be truly executable -- without
requiring an underlying Play environment -- including (and
especially!) accessing the appropriate configuration file.

Hopefully I'm just mixed up about this (as usual), and you can set me
straight. ;-)

But if this does require some tweaking, then maybe the team would also
consider reinstating some mechanism for conditionality within the
configuration files (i.e., different values for different deployment
targets). Having to maintain multiple configuration files is a sure
recipe for introducing late-stage deployment bugs, especially in more
complex, configuration-heavy environments. And these will be bugs that
we cannot, by definition, find in development. Eeek.

Kind regards,
Kenner

[peter hausel]

Hi Kenner, I will look into this. Cheers, Peter

[peter hausel]

Hi Kenner,

I just pushed a changeset that addresses this problem (I also updated the wiki with the new syntax) but essentially, now you can do

play -Dconfig.file=/myprod/application.conf start

and

play -Dconfig.file=/myprod/application.conf dist

the latter will copy the referenced application.conf into the distribution and will use that for the app (so in other words, you can leave your development config in conf/application.conf while still can build a standalone distribution with production configuration)

Hope this helps.

Cheers,

Peter

[Ben McCann]

Is it also possible to reference an external configuration?  Doing so has been very valuable for us in the past as it allows us to change configuration options without rebuilding and redeploying the entire application.

Thanks Peter!

Cheers,

Peter

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/tlh0l8ONb68J.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[peter hausel]

Hi Ben,

Yes, on top of these options I believe  

$ play dist

$ cd dist

$ unzip xxx.zip

$ cd  xxx

$ start -Dconfig.file=/myprod/application.conf

should work too.

[Ben McCann]

Great!  That's what I was hoping for =)

One more question on the topic.  Does my production version of the application.conf need to replicate all the settings or only the ones that I want to override?

Thanks,

Ben

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/kZxd4pkBnkAJ.

[peter hausel]

Hi Ben,

I just tested this "start -Dconfig.file=..." scenario, and it does work. As for your question: all settings need to be in the referenced application.conf

Cheers,

Peter

[Guillaume Bort]

Well you can have a prod.conf that includes the default
application.conf and then override some keys

include "application.conf"

application.secret=xxx

Also you can override specific keys without having to provide a full
configuration file:

start -Dapplication.secret=xxx

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/play-framework/-/1UNaBVJl9wgJ.

>
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.

--
Guillaume Bort

[Ben McCann]

Oh, perfect, that works.  Thanks guys!

[Kenner Stross]

Thanks, Peter. This work, and the "how-to" insights that you and
Guillaume have just provided, is exactly what I was looking for. I'm
away from work for a couple of days, but I'm going to give all of this
a try asap.

Thanks again.

On Jan 25, 1:11 pm, Ben McCann <b...@benmccann.com> wrote:
> Oh, perfect, that works.  Thanks guys!
>

> On Wed, Jan 25, 2012 at 1:05 PM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Well you can have a prod.conf that includes the default
> > application.conf and then override some keys
>
> > include "application.conf"
>
> > application.secret=xxx
>
> > Also you can override specific keys without having to provide a full
> > configuration file:
>
> > start -Dapplication.secret=xxx
>

> > On Wed, Jan 25, 2012 at 9:34 PM, peter hausel <peter.hau...@gmail.com>

[Havoc Pennington]

Hi,

There's one other option here as well, which is to use environment
variables with the ${?FOO} optional-substitution syntax.

In application.conf do something like:

whatever.secret=defaultdevsecret
whatever.secret=${?PRODUCTION_SECRET}

Now in production, set PRODUCTION_SECRET=something in the environment
to override defaultdevsecret.

This is especially suited to Heroku deployments which use environment
variables but could also make sense in other setups.

Caveat: this was broken until config lib 0.2.1, which was just now
copied in to Akka master, so it won't work until the next Akka
milestone release.

Havoc

[Pyppe]

Hi.

I am having difficulties using environment-specific config-files.

For example, I have "my-env.properties", which has:
--- start my-env.properties --
include "application.conf"
some.new.property=foobar
--- end

If I start the application like this: play "run -Dconfig.file=conf/my-env.properties", then I can get the some.new.property value as expected. BUT I cannot get the original values from application.conf. For example; Play.current.configuration.getString("application.secret").getOrElse("-") outputs "-".

What am I missing here? :\

- Pyppe

> > > To post to this group, send email to play-framework@googlegroups.com.

> > > To unsubscribe from this group, send email to

> > > play-framework+unsubscribe@googlegroups.com.

> > > For more options, visit this group at
> > >http://groups.google.com/group/play-framework?hl=en.
>
> > --
> > Guillaume Bort
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.

> > To post to this group, send email to play-framework@googlegroups.com.

> > To unsubscribe from this group, send email to

> > play-framework+unsubscribe@googlegroups.com.

[Havoc Pennington]

Hi,

On Wed, Apr 18, 2012 at 11:55 AM, Pyppe <pyry....@gmail.com> wrote:
> Hi.
>
> I am having difficulties using environment-specific config-files.
>
> For example, I have "my-env.properties", which has:
> --- start my-env.properties --
> include "application.conf"
> some.new.property=foobar
> --- end
>

properties files don't support includes - they are just regular java
properties files - try renaming it my-env.conf

Java properties syntax parses almost anything as a valid file, in this case

scala> val p = new java.util.Properties(); p.load(new
java.io.StringReader("""include "application.conf""""))
p: java.util.Properties = {include="application.conf"}

so that's why you didn't get an error.

Havoc