In windows java parmeters are not received

[gastonfournier]

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:
myattr=default
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

[jsuereth]

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]

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.

API

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]

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

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]

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

https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/windows/WixHelper.scala#L119-L124

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]

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

[gastonfournier]

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]

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

SO,

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

https://github.com/sbt/sbt-native-packager/blob/master/src/main/resources/com/typesafe/sbt/packager/archetypes/bat-template#L20-L30

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!

[kmcswiney]

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:

set _JAVA_OPTS=%JAVA_OPTS%
to:
set _JAVA_OPTS=%JAVA_OPTS% %*

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

[muuki88]

Thanks for sharing. So the above call

bin\test.bat -Dmyattr=changed

the %* would be -Dmyattr=changed then?

[jsuereth]

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?

[kmcswiney]

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

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

[kmcswiney]

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.

[eranation]

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?
Thanks!

[jsuereth]

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.

[eranation]

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

https://github.com/sbt/sbt-native-packager/blob/v0.7.0-M1/src/main/resources/com/typesafe/sbt/packager/archetypes/bat-template#L81

"%_JAVACMD%" %_JAVA_OPTS% %@@APP_ENV_NAME@@_OPTS% -cp "%APP_CLASSPATH%" %APP_MAIN_CLASS% %*

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