Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

In windows java parmeters are not received #155

gastonfournier opened this Issue Feb 5, 2014 · 17 comments


None yet
5 participants

If you pack any play application and then open the generated .bat you'll see at the bottom:
rem TODO - figure out how to pass arguments.... "%_JAVACMD%" %_JAVA_OPTS% %TEST_OPTS% -cp "%APP_CLASSPATH%" %APP_MAIN_CLASS% %CMDS%
I think that TODO si what is missing.

How to reproduce:
Running on Linux with play 2.2.1 built with Scala 2.10.2 (running Java 1.7.0_51) and sbt 0.13.1

$ play new test
Choose scala project
$ cd test play dist
Edit conf/application.conf and add the following at the end:
In the default controller append Play.application.configuration.getString("myattr") to the end of the string. Also add the import: import play.Play
def index = Action { Ok(views.html.index("Your new application is ready."+Play.application.configuration.getString("myattr"))) }
$ play dist
In windows, uncompress it and then run

bin\test.bat -Dmyattr=changed
If you open localhost:9000 you should see:
Your new application is ready.default
instead of the desired
Your new application is ready.changed

A workaround:

set JAVA_OPTS=%JAVA_OPTS% -Dmyattr=changed
And then run
Then It'll be working


jsuereth commented Feb 6, 2014

this is by design for now. If you have a good mechanism whereby we can do the same kind of parameter parsing done on the linux side (check out the bash template where we special handle -J/-D options) so that arguments are correctly passed to either the JVM or the process itself, I'm more than willing to accept such a patch. As it stands this is a known limitation, not a bug. marking this as a feature request I'd love to have. My "bat fu" isn't as good as my "bash fu".


muuki88 commented Feb 6, 2014

For the server_archetype I'm planning to make use of the standard behavior of the Typesafe Config Library

This was discussed briefly here: #140

The standard behavior states all resources on classpath with this name,
so you application should ship a reference.conf and
you can place an application.conf in, e.g. /etc/your-app/.

The API for this must:

  • Add packageMapping for this directory
  • May add packageMapping for the config-file
  • prepend this folder to the classpath

Windows Question

Is there a default configuration location for windows (server)? I'm aware of a few under C:\\Users\user-name\, e.g. AppData\Local, AppData\Roaming.


Configuring this behavior needs to extend the classpath, so there maybe something like this:

applicationConfig in Linux := Some("/etc/" + normalizedName.value)

applicationConfig in Windows := Some("C:\\Users\<username>\AppData\Local\" + normalizedName.value)

jsuereth commented Feb 6, 2014

@muuki88 I'm a bit nervous of throwing system directories into the classpath (security vulnerabilities). I'll take that up with @havocp though on the typesafe config library. Could be "best practice" needs to change, but for now being friendly to typesafe-config feels the right way to go.


muuki88 commented Feb 6, 2014

This shouldn't be system directories. For linux this could be /etc/yourapp/conf which is owned by the application.

Windows is a different story. I have no experience what's "best practices" here. I'm only aware of the user home folder.


jsuereth commented Feb 6, 2014

You can actually mark files in the system directory as user writeable. It's a bit odd. See:


Not sure if this is best practice or not, but it's what we do for sbt. I haven't had a chance to pick the brain of a windows sys-admin in a few years, however the ones I knew were using graphical tools or powershell. Neither really applies here....


muuki88 commented Feb 7, 2014

@gastonfournier , do you have any insights on this? Where do you install your application (windows version, etc)?

Hi @muuki88, the problem is not about installing the application, but to passing parameters to it. The application is standalone and self-contained, I agree with @jsuereth that throwing system directories into the classpath is a security risk.

The idea is to unpack the application and configure it to "watch" (same concept than in compass: http://compass-style.org), and that watch directory may be specified with the -Dwatch parameter. It's possible to use Typesafe Config Library but it's not what I'm looking for.

@jsuereth agree, must be a feature request. I'm not an expert in Windows .bat, but I'll see if I can collaborate with some code for the same kind of parameter parsing done on the linux side (God I love linux!)


jsuereth commented Feb 7, 2014

yeah, so as far as BAT-fu goes, I learned how to parse a file and load all its lines into a variable which replaces/joins JAVA_OPTS already. HOWEVER, any kind of sophistication in this is beyond my abilities currently, but I do love a good challenge (which I'll issue to you :) ).


Here is the routine which reads all lines from the file:


This requires the "delayed expansion" flag, because bat files have VERY odd execution/scope semantics. It's possible to do pattern-matchy things with a FOR variable, but I'm not quite sure how to funnel all the data in variables to a final coherent result. Ideas more than welcome!

I'm experiencing this issue as well while trying to deploy a Play app to Windows, and I was able to get past it by changing this line:


The %* just appends all the command line arguments... does that help at all?


muuki88 commented Feb 12, 2014

Thanks for sharing. So the above call

bin\test.bat -Dmyattr=changed

the %* would be -Dmyattr=changed then?


jsuereth commented Feb 12, 2014

The issue is that if we do that, then command line arguments are completely indistinguishible from JAVA_OPTS.

E.g. the native packager is designed to work with things that have a main method, and arguments should be passed there.

As I stated previously, you should use the config file for java options (CFG_OPTS) of servers. If we document how to do this with play, would that be enough?

@muuki88, yep that's right, the %* will be replaced with whatever your command line args are.

@jsuereth, sure, is that workaround you mentioned a one-off thing you'd do for a given server? If it gets around having to hand-edit the start script after each build, then it would be a huge help.


jsuereth commented Feb 12, 2014

Well, what do you think of using this kind of a loop to parse out windows arguments similarly to the linux script? http://stackoverflow.com/questions/3973824/windows-bat-file-optional-argument-parsing

Good find... so you check if %1 is empty, and if not, accept it as an argument and use SHIFT to move to the next one. Sounds like a plan.

Any news on that? any help needed? My use case is quite simple, I develop a command line app, and was expecting that the bat file generated by the stage command will let me do this:

myfile.bat --myparam myvalue

which will lead to having these passed as args to the main method

Is that what we are all discussing?
What was the problem with adding %* after all the other env variables? It works for me, and seems like the standard way to pipe the bat arguments around. I missed to see the issue. (I don't mind sending this as a pull request, but in my experience if a pull request is a trivial fix, it's probably wrong)
What am I missing?


jsuereth commented Feb 21, 2014

Ah, the issue was more how we pass arguments so that the bat script and bash script are in line. If you want to submit a PR so that %* are sent as arguments to the process, that's ok. However, correctly parsing -D,-J,-mem arguments is something I'd like to have when we do that to limit documentation required and confusion.

Also note: In 0.7.0-M2+ the template is configurable.

Hm... I guess no need for a PR... %* is already in since 0.7.0-M1



I'll test it but I guess you can close this issue :)

@muuki88 muuki88 added this to the 0.8.0 - windows services milestone Mar 12, 2014

@muuki88 muuki88 closed this May 17, 2014

@mauriciojost mauriciojost referenced this issue in mauriciojost/olympus-photosync Mar 16, 2017


Cannot change configuration parameters #22

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment