I've been trying to get my Rails application to work TorqueBox and one of its requirements is to use JRuby as the Ruby language variant. I've installed JRuby 1.6.6 and the gemfile seems to bundle itself properly, but when the rails server is booted up and accessed within a browser (at localhost:3000 or 0.0.0.0:3000) then the webpage hangs...
I'm not sure if this is a problem with Rails 3.2 and the rails server does start fine (doesn't show any errors within the console) and the Rails 3.2 instance does work with Ruby 1.9.2. So I think it may be something with my gem file list or perhaps something within an initializer.
Any ideas if this is a common problem?
--- EDIT ---
I'm trying to access 0.0.0.0:3000 from WebBrick.
As far as I know torquebox 2.0 beta 3 is currently tested with jruby 1.6.5.1. Maybe try switching to that jruby version. Also make sure you're running ruby in 1.9 mode. To do that, create a torquebox.yml file in your rails config folder and put the below in it:
ruby:
version: 1.9
Related
I installed, both JRuby and Ruby, and also Rails. To create a new application I just type
rails new app_name
And an application gets created. So is this application Ruby or JRuby?
You could detect your ruby version by running ruby -v.
However, I would highly suggest you use RVM to manage your ruby versions if you can. This will allow you to quickly switch between full Ruby environments that are completely isolated.
If you are using RVM, just go into the rails app directory, and type
ruby -v
on the command prompt, you will get to know which ruby you are using.
Within Ruby, you can check the RUBY_ENGINE constant ("ruby" in normal MRI Ruby, "jruby" in JRuby).
Unfortunately, this constant is not defined in older versions of Ruby, so you should check with defined?(RUBY_ENGINE) if it exsits.
Executing 'rails' command using JRuby produces the same "pure" Rails project as pure (aka MRI) Ruby does.
MRI Ruby application "becomes" JRuby application when you run it with the JRuby interpreter instead of the pure Ruby one. The is a runtime difference.
Of course your bare Rails application won't work properly with JRuby interpreter until you configure it to use JRuby gems (JDBC). Please note also that it is possible to create Rails application that can properly run both under JRuby and MRI Ruby.
At work for internal Rails applications, the server is running Rails 2.0.4 and Ruby 1.86. As far as I know, that's not going to change anytime soon and I have no control over it. I was going to try and test this out between a couple of computers and was curious if anyone knew what would happen.
Being the server is on 2.0.4, I'd like to build Rails 2.3.5 applications for that server if at all possible. From what I understand so far, it won't be a problem if I freeze gems and upack dependancies. Does that sound right?
Also, the internal work server has no gems beyond what Rails installs. What I'm wondering is, if I can successfully run a 2.3.5 application on the 2.0.4 server, can I also use extra gems and unpack those to use even though the server doesn't have them? I know that it was version 2.1 that introduced Gem Dependencies so would a 2.3.5 Rails app running on a 2.0.4 server be able to use required gems that are unpacked into an application?
One of the worst things with this situation is even if the above stuff works, the server being on 1.86 would exclude me from using a lot of really cool gems that require Ruby 1.87 (like Formtastic).
Thanks
You can manually specify the version of Rails being used in the application in the conf/environment.rb file with the RAILS_GEM_VERSION variable.
You won't be able to gems that aren't installed on your server because the application won't be able to find the libraries.
I went ahead and did the leg work to test this out. If this helps anyone else:
Rails 2.3.5 will run fine on a 2.0.x server.
With Rails 2.1 or above, you can unpack gems and your app will work on a 2.0.x server (lower version server). These are the steps I took in order. The only thing unique here is the Rack version is specific to Rails 2.3.5 (and below). In version 2.3.6 and up they switched to rack 1.1. I'm sticking to 2.3.5 because of the Rack issues with 2.3.6 and up, like broken multipart uploads).
(inside your application directory).
rake rails:freeze:gems
rake gems:unpack:dependencies
(Create a Gems Folder in the vendor folder if it's not there)
(Navigate inside the gems folder: your_app\vendor\gems)
gem unpack rack -v="1.0.1"
(There should now be a folder called "rack-1.0.1" inside the gem folder)
(Navigate back out to your application root folder)
rake gems:refresh_specs
I tested this out using the authlogic gem - moving the project over to a spare laptop that only had Rails 2.0.4 installed and no other gems (except MySQL and Mongrel). The only thing I'm not sure about yet is if a gem that requires a script file be run for installation after the gem file (like Simple Forms) will work. I'm going to test that out next when I get time.
In my env I require 3.0.3
but when I script/server
I get this: can't activate rails (= 2.3.8, runtime) for [], already activated rails-3.0.3
I don't want it to activate 2.3.8.. =\
Rails 3.x doesn't use script/server anymore - you should run your server with rails server or rails s. You can delete all the files from script, except for script\rails.
Plus, you no longer specify your Rails version in environment.rb (if that's what you mean by "env"). All gems and their versions are specified in your Gemfile.
Did you follow a guide like Upgrading to Rails 3? It's not enough to just change the Rails version in evironment.rb.
The command to run the server in Rails 3 is rails server. What happens if you run that?
Rails 3 uses
rails server
command instead of
ruby script/server
Check environment.rb to make sure that you're not specifying rails 2.3.8 explicitly. If you are then you need to make sure you've upgraded to bundler properly.
My suggestion is to generate an empty rails 3 project and look at how the generated files and make sure your app looks similar.
I have developed a Ruby on Rails application and successfully deployed on Weblogic using Jruby and Warbler (which creates a war file based on the settings in config/warble.rb).
I believe although Jruby comes with inbuilt Ruby 1.8 and 1.9, by default it uses 1.8 and I want to test the same rails application in Ruby 1.9 within JRuby as I heard that Ruby 1.9 is a lot faster than 1.8. I do not see any configuration option in warble.rb
where we can specify to use Ruby version to use. Whats the best way to force Jruby to use Ruby 1.9?
Also my Rails application is based on Rails 2.3.2, are there any compatability issues on running rails application (built on 2.3.2) on Ruby 1.9? If so will upgrading rails to 2.3.5 solve the problem?
Thanks in advance.
you specify it as an argument on the command line
jruby --1.9 -v
Don't know about the compatibility issues.
I follow configuration guide of JRuby https://github.com/jruby/jruby/wiki/ConfiguringJRuby and it work.
Create .jrubyrc in user directory (C:\Users\tvo1510 on Window 7) with content:
compat.version=1.9
It's done.
Cheers,
in config/warble.rb, look for this line:
# config.webxml.jruby.compat.version = "1.9"
uncomment it and re-run warble.
says if i develop a Ruby on Rails application using Rails 2.3.2, will that usually be compatible with Passenger on my hosting company?
If i ssh to my hosting company and type rails -v, i get 2.2.2... so looks like they might be using Rails 2.2.2.
So if i develop a Rails app on my Macbook and ftp all files over there, will the Passenger there usually work well with the generated code with the current version of Rails?
Freeze rails into vendor/rails using the built in rake task. That way your app will ue the version of rails you want it to no matter where you deploy it.
rake rails:freeze:gems
And the easiest way to do a specific version I know of.
rake rails:freeze:edge RELEASE=2.3.2.1
Now your version of rails will go with you where you send your app.
You can unpack other gem dependencies into vendor/gems for any gem you are using and want to be sure that it is available where ever you deploy the application.
rake gems:unpack
And to ensure their dependencies go to:
rake gems:unpack:dependencies
I would also suggest that you verify that they are running the latest version of passenger.
I would verify the version of Passenger they have installed (or confirm they have it installed at all). I would also suggest you freeze your version of Rails.
Just second something for railsninja's answer .
First say, it won't work straightaway.
Is that host a vps to you or have sudo access somehow?
If yes, I suggest you to do rake gems:install instead of gems:unpack, because some of gems are os dependent e.g (Rcov, RedCloth...etc.)
I will ask the hosting company of their passenger's configuration, the important question will be if they use RailsSpawnMethod: smart or smart-lv2(default).If they use the smart method, then it is a better idea to freeze your gems and rails otherwise will have the compatible issue as you can find reference from passenger user manual about the RailsSpawnMethod.
It will be nearly 100% compatible if you freeze your gems(all the gems need to be declared correctly in the environment.rb with config.gem, e.g(config.gem 'will_paginate',:source=>"http://gems.github.com")) and RAILS!!!!!