First, I tried upgrading to Rails 2.x. Don't try this. If you're not a professional Rails developer, you'll likely tear your hair out and ask yourself why you ever decided to use Rails in the first place. In my case, upgrading would have required a near total re-write of the (very simple) app.
For the impatient, here's the basic gist of what I did.
- update config/boot.rb, require_gem -> gem
- freeze to edge, RELEASE=1.1.4
- reset config/boot.rb(?) -> rake rails:update
- pluginize warbler
- update environment.rb
- create jboss-web.xml
- create -ds.xml file
- create warble.rb
- update warble.rb
- update database.yml -- copy production: block
- update new/thankyou.rhtml (change absolute links)
- add close_connections.rb
- edit new_rails_defaults.rb
I used JRuby 1.2.0 on a Rails 1.1.4 app, deploying to a JBoss 4.2.0.GA application server against a MySQL 4.1 database.
This isn't meant to be a list you can work off, merely a list showing what's involved, so if you count yourself amongst the faint of heart, stop here :).
update config/boot.rb, require_gem -> gem
If you don't actually have the original RubyGems that you had when you started your Rails 1.x project, some things have changed. Most particularly, require_gem is no longer deprecated, its GONE! So, edit
config/boot.rbby changing the two instances of require_gem to simply gem. That wasn't too hard :)
freeze to edge, RELEASE=1.1.4
Now you're ready to freeze. You really want to freeze because it will simplify things down the road for your warbler tasks and runtime within JRuby. Until I froze, I kept having oodles of issues that basically track down to various commands trying to do things in my Rails project whilst executing code from the latest Rails on my system (2.3.2, I think). You should be able to freeze to just about any RELEASE or TAG you want. Either of the following should work:
$ rake rails:freeze:edge TAG=rel_1-1-4
$ rake rails:freeze:edge RELEASE=1.1.4
reset config/boot.rb(?) -> rake rails:update
Guess what? Now we need to undo step #2. But, this is pretty easy. You can either manually revert the changes you made to boot.rb, or just run:
$ rake rails:update
Which, contrary to its name, shouldn't do anything terribly crazy other than reset your boot.rb back to what it was previously (and it does this now based on your *frozen* Rails, not whatever the latest is in your system).
pluginize warbler
Assuming you've installed Warbler (if you haven't, gem install warbler) - let's take the road less travelled and pluginize. This keeps everything in a nice local package. It also means you can use the normal rake commands instead of
jruby -S warble <cmd>
Alright, to pluginize, straight from warbler's docs:
$ jruby -S warble pluginize
update environment.rb
Not sure where I found this, but it appears to be essential. Running in the JRuby environment appears to take a a few gems that aren't included elsewhere, so update your
config/environment.rbto include the following:
if RUBY_PLATFORM =~ /java/
require 'rubygems'
RAILS_CONNECTION_ADAPTERS = %w(jdbcmysql)
require 'active_record'
gem 'activerecord-jdbcmysql-adapter'
require 'active_record/connection_adapters/jdbcmysql_adapter'
end
Insert this immediately preceding the line that looks like this:
Rails::Initializer.run do |config|
create jboss-web.xml
I wanted to create a configuration that takes advantage of JBoss' connection pools for connections to MySQL, unfortunately (dirty secret), I haven't gotten it to work yet. Soooo, you can consider this step optional. Once I figure out what piece is missing to get JNDI DataSource access working, however, this piece will certainly be needed, so, take it or leave it :)
The jboss-web.xml maps an application-local resource-ref to a global JNDI name. Typically used to map a 'generic' JNDI ref such as jdbc/rails to a specific ref, such as jdbc/my_cool_apps/app1. Of course, you could just use jdbc/my_cool_apps/app1, but the thinking is that a level of indirection helps when you need to change things - you just change a config at the container level and don't need to muck about with the app (repackaging/redeploying/etc.). Again, YMMV, take it or leave it.
Here it is:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<resource-ref>
<res-ref-name>jdbc/rails</res-ref-name>
<jndi-name>jdbc/my_cool_apps/app1</jndi-name>
</resource-ref>
</jboss-web>
create -ds.xml file
Now that you've mapped the local JNDI name to the global JNDI name, you should probably setup the configuration in JBoss that creates the global JNDI name. Here it is (substitute in your own parameters):
<?xml version="1.0" encoding="ISO-8859-1"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/my_cool_apps/app1</jndi-name>
<connection-url>jdbc:mysql://mysql.example.com:3306/mydb</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>my_username</user-name>
<password>secret</password>
<!-- Typemapping for JBoss 4.0 -->
<metadata>
<type-mapping>mySQL</type-mapping>
</metadata>
</local-tx-datasource>
</datasources>
This by far isn't the most sophisticated DataSource you can configure, but there are better references elsewhere for the options available.
This gets dropped in the JBoss application server's "deploy" directory to setup the DataSource in global JNDI.
create warble.rb
Alright, back to the app. Let's create the warble config file, mostly run on defaults, but we need a couple customizations.
$ jruby -S warble config
-OR-
$ script/generate warble
I had some issues with the latter, can't remember if that was before I figured out I needed to freeze, but the first way worked for me, YMMV.
update warble.rb
Documentation for warbler contains oodles of information on configuring, I found no fault with that information. Here's what I did:
Added
config.includes = FileList["jboss-web.xml"]
config.gems += ["activerecord-jdbcmysql-adapter"]
Set
config.gems["rails"] = "1.1.4"
(use whatever version suits you)
Uncommented
config.webxml.jndi = 'jdbc/rails'
That's it!
update database.yml -- copy production: block
So, here's where, if the world were a happy place, I'd tell you how to configure database.yml to use JNDI. Unfortunately, following the available documentation, I haven't gotten this to work. So, instead, I'll show you how to switch to use the 'jdbcmysql' adapter, instead of the 'mysql' adapter.
Change
adapter: mysql
To
adapter: jdbcmysql
Painful, I know. You'll need to use a host: parameter, too, JDBC doesn't connect to /tmp/mysql.sock.
update new/thankyou.rhtml (change absolute links)
Not sure this applies to everyone, by my .rhtml files had absolute references in them to static resources. That needs to change to use relative paths that resolve to within your application. Just removing the leading '/' did the trick for me.
add close_connections.rb
This may be an optional step, I think its only needed if you do use JNDI (not in use here, yet). In any case, you'll want to add an initializers/close_connections.rb to config in your app. Contents:
if defined?($servlet_context)
require 'action_controller/dispatcher'
ActionController::Dispatcher.after_dispatch do
ActiveRecord::Base.clear_active_connections!
end
end
edit new_rails_defaults.rb
Finally (are you still reading?!), the spec for warbler uses a Rails 2.x (I think) JSON config, this needs to be commented out. Find your new_rails_defaults.rb under vendor/plugins/warbler-0.9.13 (version may vary), and comment out the last line.
#ActiveSupport.escape_html_entities_in_json = false
That's it!! Seriously.
Use a line like this to package/repackage/deploy your .WAR and enjoy.
rake war:clean; rake war; \
if [ -e <rails_app>.war ]; then
unzip -q -o -d $JBOSS_HOME/server/default/deploy/<rails_app>.new <rails_app>.war;
mv $JBOSS_HOME/server/default/deploy/<rails_app>.war $JBOSS_HOME/server/default/deploy/<rails_app>.old;
mv $JBOSS_HOME/server/default/deploy/<rails_app>.new $JBOSS_HOME/server/default/deploy/<rails_app>.war;
rm -rf $JBOSS_HOME/server/default/deploy/<rails_app>.old ;
fi
Where <rails_app> is your app name; $JBOSS_HOME is set to your JBoss install dir. BEWARE - I chased my tail AROUND AND AROUND because I didn't realize that (a) rake war doesn't clean tmp/war before setting up & repackaging the WAR, so if you're trying to fix things, your old stuff may still be around; similarly, unless you're deploying the packaged WAR file, JBoss doesn't do you any favors and you should remove the exploded WAR before placing your fresh WAR dir in the deploy dir.
