JRUBY_OPTS is misinterpreted

[tolsen]

It appears that JRUBY_OPTS is misinterpreted as if it were just another JAVA_OPTS. See https://github.com/trinidad/trinidad_init_services/blob/master/init.d/trinidad.erb#L96

This is preventing me from passing --profile.api as a jruby option. When I set JRUBY_OPTS to --profile.api , I get:

Starting trinidad daemon...
Invalid option --profile.api

Cannot parse command line arguments

Daemon exited with status: 1. Check pidfile and log

[kares]

Yeah, thanks I'll simply remove JRUBY_OPTS to avoid confusion.
Please note that unless you did some tweaking what you're trying to accomplish won't work anyway :

1. the daemon does not parse JRUBY_OPTS as fas as I know
2. profiling does not work correctly with a non-global runtime (Trinidad sets up new JRuby runtimes for apps)

[tolsen]

Yeah, I tried removing JRUBY_OPTS from the init script like you did but could not get the profiling to work. Something did parse JRUBY_OPTS (I think jruby does parse it), but the profile dumped was empty of any methods. I've since taken to running under WeBrick for profiles.

But I agree, JRUBY_OPTS should be removed. Thanks!

[wndxlori]

New wrinkle... Capistrano deployment... I need JRUBY_OPTS with --1.9 or my capistrano-invoked rake tasks fail with odd hash syntax errors, but then the 'cap deploy:start' fails on - Invalid option --1.9.

Any ideas on how to get around that?

[kares]

use smt like jruby --1.9 -S rake as rake in capistrano ...