Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

In windows java parmeters are not received #155

Closed
gastonfournier opened this Issue · 17 comments

5 participants

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

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
Collaborator

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
Owner

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

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
Owner

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
Collaborator

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

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
Collaborator

Thanks for sharing. So the above call

bin\test.bat -Dmyattr=changed

the %* would be -Dmyattr=changed then?

@jsuereth
Owner

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
Owner

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
Owner

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

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