Posted by davidrupp
on March 20, 2007 at 10:45 AM PDT
Two great tastes? Or one sticky mess?
I've been following Brian Leonard 's recent entries on JRuby/Ruby/Rails integration in the latest NetBeans milestone release. In my own tinkering to solidify what I've learned from Brian, I've found that there are a couple of showstoppers that will prevent me from using this suite for serious Rails development, for now at least.
You see, Brian's JRuby example was ported directly from the original how-to screencast created by David Heinemeier Hansson, the creator of Rails. The techniques in the screencast were state-of-the-art back then, but a lot has changed in the two-plus years since it first hit the internet.
One of the major changes is that Rails now prefers Mongrel as its application server. The script that starts the server (script/server) looks for an installation of Mongrel first, then for LigHTTPD to serve a Rails app. If neither of those is available on your system, Rails will fall back to using WEBrick, which comes bundled with Ruby. WEBrick works great for local development and testing, but it's not suitable for use in production. So using WEBrick for development can lead to one of two problems:
You decide to deploy in production using WEBrick anyway, because it's what you're used to.
You deploy in production to Mongrel, but you don't understand it because you're used to developing on WEBrick.
So ideally I would like to be able to make NetBeans aware of Mongrel, since it doesn't come as one of the bundled gems in the Ruby Feature. And that's where the fun starts.
NetBeans thoughtfully provides an interface for managing my Ruby Gems (at Tools/Ruby Gem Manager). Once there I click on "Install New...", wait for the "Available Gems:" area to populate, scroll down to the entry for mongrel, select it, and click Install. On the "Gem Installation Settings" screen I accept the defaults (install the latest version of the gem and include dependencies) and click OK. Which brings me to:
Mongrel, like many other gems out there in RubyLand asks (actually, requires) me to select a specific gem for my version and platform. Unfortunately, the NetBeans interface does not (currently) allow me to interact with the gem install process, so I'm stuck. By the way, philosophically I consider this a flaw in the gem installation process, not in the NetBeans interface. I don't like having to make this input on the command line either. But since this mechanism isn't likely to change soon, it's unfortunately up to the NetBeans team to provide an interface to it. Which I know is on their List of Things To Do.
Back to installing mongrel. As it happens I'm used to manually installing my gems anyway, so it shouldn't be too much trouble for me to locate the NetBeans gem repository and install mongrel by hand. I just need to know where the 'gem' command lives relative to my NetBeans/JRuby installation. It happens that there's a setting for this, under Preferences.../Miscellaneous/Ruby Installation. On my machine (running Mac OS X), the major executables live in the ~/.netbeans/dev/jruby-0.9.8/bin/ directory. A quick inspection of this directory verifies that the 'gem' command lives there too. So I just need to define a JRUBY_HOME that points to that jruby directory, and add $JRUBY_HOME/bin to the front of my PATH.
(Note to Windows users: Sorry for all the Mac/Unix-isms. All of this stuff is directly analogous to setting environment variables via the usual Control Panel/System/Advanced dance that you get to do. Hopefully you're used enough to it by now that you can just figure it out.)
Now with my PATH set properly I can do 'gem install -y mongrel' by hand. I get the same list of options, and I respond by selecting the latest and greatest. Which brings me to:
Mongrel, like a bunch of other "Ruby" gems actually requires access to native C libraries, which get built as part of the installation process. Which causes the JRuby gem installer to fail miserably. Bummer. To make things worse, according to the JRuby FAQ , native library access will never be available from JRuby. Double bummer.
The punch line? No Mongrel on JRuby, at least until someone implements the C-specific stuff in either Java or Ruby (or JRuby, I guess). The good news is that some gem providers are starting to re-work their gems and provide JRuby-capable versions for them.
The other good news is I can still use good old WEBrick in JRuby. It's not the end of the world. But it'll sure be nice to have access to Mongrel, whenever that happens. And the install-gems-by-hand trick works nicely for gems that don't involve native libraries. Try it with 'gem install gem_plugin' if you need proof. The only downside is that the NetBeans Ruby Gem Manager doesn't become aware of any hand-installed gems until you restart. Again, this is more of a nuisance than an actual hindrance.