Add JRuby support#24
Conversation
|
That is hot! |
|
tarcieri, it's been a while since I followed jruby, but did you intend to leave the manifest version at "1.8.7p330" for jruby? With the appropriate version, it might be a short path to use rvm for jruby as well in local installs. Thanks for exploring |
|
I originally set the manifest version to 1.6.1. However, cloud_controller seems to be checking against RUBY_VERSION, which JRuby reports as 1.8.7p330 when running in 1.8 mode. When I had the manifest version set to 1.6.1, cloud_controller wouldn't even start. JRuby reports its own version via JRUBY_VERSION. That said it'd probably make sense to have separate "jruby18" and "jruby19" runtimes to match the ruby18 and ruby19 runtimes. This can be accomplished by adding the --1.9 flag to JRuby. Maybe I'll put together a quick patch for that. I agree rvm is definitely the way to go in the long run. |
|
Well, jruby18 works but jruby19 does not. cloud_controller starts but I'm having a bit of trouble determining why applications won't launch under the jruby19 runtime. Can "executable" not take arguments and if not, is there a proper way to pass them? |
|
We'll get reviewed and pulled shortly, pending any feedback. That being said, before we can pull it, we want to add the ability to enable/disable frameworks so that we don't disrupt the large production system at Cloud Foundry until this has been through our load/stress tests. We'll enable it in the Microcloud context out of the gate though. Thanks! |
|
Tarcieri, did you a corresponding vcap-tests for this? I didn't see one. At a minimum we will need something that pushes an app that uses the framework and hits a url on it to make sure that the app launched correctly and is responding to end user requests. If you do any auto-wiring of services, i.e. rewriting DB connection strings or something like the spring framework does, then a test for that too. We can't pull this until we have a test. We can eventually do one for it, but it will delay the pull. If you could submit one that goes with this, that would be awesome. |
|
Whoops, commented as the wrong user :) Unfortunately I didn't write a test for it yet. I'll see about writing one. In addition the jruby19 runtime should be disabled as it's not working. |
|
If it's just the --1.9 arg that is a problem with the jruby19 runtime, can you test out wrapping that into script? If that doesn't solve it - it'd be helpful to know if it fails during staging or when starting the app. |
|
Using a wrapper script solves the problem. I can look into writing a test as well. |
|
Just a reminder.. we will need a vcap-tests pull request to go with this before we can pull it. Thanks! |
|
I'm a bit preoccupied with other open source projects right now, but if I get some time I'll look at writing a corresponding test for vcap-tests. I think what would be particularly helpful is a description of the workflow for committing code which requires modifications to vcap-tests. As it's a git submodule I think it's a lot less straightforward that contributing to other parts of the codebase. I think I'd need to fork vcap-tests, reconfigure the submodule to pull from my fork, update the submodules, then begin making my modifications. A clear set of instructions as to how to do this would be incredibly helpful. |
|
We are very interested in seeing this come to closure. Since it may be awhile, we're going to close the request until it is ready to be resubmitted. As for creating a test, just fork the test repo and make your changes. You don't have to update the submodule pointer. We'll do that after we merge. Thanks |
|
Just saw this thread. We are VERY interested in getting JRuby on CloudFoundry |
|
I believe it already is.. albeit not sure if the latest version of JRuby is being used? |
5 participants
I'm aware you can deploy warbled Rack applications into the Java runtime. That said, this allows you to deploy natively onto JRuby just as you would any other Ruby interpreter without the need to warble your application.
On my local copy of vcap I edited the staging manifest for Sinatra and made jruby the default runtime. I was successfully able to launch a "Hello, world!" Sinatra app on JRuby with this configuration. It launched under Thin through JRuby 1.6's C extension support. Real world usage of JRuby should probably launch the trinidad web server instead of thin, which I had the setup script install but didn't yet add to the manifest.
As far as I can tell there's no other way to select a runtime other than hand editing the manifest files, so I'm not sure how useful this is right now or if it's even wanted. All that said, it's at the proof-of-concept stage and works with Sinatra.