Skip to content


Subversion checkout URL

You can clone with
Download ZIP


In windows java parmeters are not received #155

gastonfournier opened this Issue · 17 comments

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....

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
> bin\test.bat
Then It'll be working


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".


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)

@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.


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.


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....


@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:, 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!)


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?


Thanks for sharing. So the above call

bin\test.bat -Dmyattr=changed

the %* would be -Dmyattr=changed then?


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.


Well, what do you think of using this kind of a loop to parse out windows arguments similarly to the linux script?


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?


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
@muuki88 muuki88 closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.