Nick Sieger: Tag jruby

activerecord-jdbc-adapter 1.0.0

2010-10-14T15:25:51+00:00

Just a quick note that activerecord-jdbc-adapter has finally hit 1.0.0. Install it today:

gem install activerecord-jdbc-adapter

Included are adapters for MySQL, PostgreSQL, SQLite3, Derby, HSQLDB, H2, and Microsoft SQL Server.

gem install activerecord-jdbcmysql-adapter
gem install activerecord-jdbcpostgresql-adapter
gem install activerecord-jdbcsqlite3-adapter
gem install activerecord-jdbcderby-adapter
gem install activerecord-jdbchsqldb-adapter
gem install activerecord-jdbch2-adapter
gem install activerecord-jdbcmssql-adapter

You can also use activerecord-jdbc-adapter with Oracle, DB2, Sybase, and Informix. Just ensure that the database JDBC driver jar files are mentioned in $CLASSPATH or require them directly in your script or application. Then, configure database.yml with adapter: set to one of oracle, db2, sybase, or informix.

This release promises superb compatibility with Rails 3. We now have the ActiveRecord test suite running in CI and the 1.0.0 release is 100% green when run on MySQL. (SQLite3 is right behind with just 13 failures, and we hope to fix those soon.)

As mentioned before, to get started with Rails 3, JRuby and activerecord-jdbc-adapter, simply run:

$ rails new app --database mysql --template http://jruby.org
   ...
   apply  http://jruby.org
   apply    http://jruby.org/templates/default.rb
    gsub      Gemfile
    gsub      config/database.yml
$ cd app && bundle install
...
Using activerecord-jdbc-adapter (1.0.0) 
...
Using jdbc-mysql (5.0.4) 
...
Using rails (3.0.0) 
Your bundle is complete! Use `bundle show [gemname]` ...

One new feature in 1.0.0 is the ability to define an extension adapter for your proprietary JDBC database without needing to hack the activerecord-jdbc-adapter source code. To get you started we extracted the activerecord-cachedb-adapter and put it on Github for you to use as a template.

The 1.0.0 release had over 200 commits poured into it and lots of great help from the community. Thanks to David Kellum, Dmitry Denisov, Dwayne Litzenberger, Gregor Schmidt, James Walker, John Duff, Joshua Suggs, Nicholas J Kreucher, Peter Donald, Geoff Longman, Uwe Kubosch, Youhei Kondou, Michael Pitman, Alex B, and Ryan Bell for their contributions to this release.

Enjoy!

JRuby at JavaZone 2010

2010-08-30T17:12:07+00:00

I’m pleased to be able to return to Oslo for JavaZone 2010. Whether you’re checking out JRuby for the first time or a veteran JRuby user, I’ll have something for you! And if I don’t, I encourage you to come badger me after the talk is finished.

JRuby: Now With More J!

Additionally, if you’re interested in meeting up for some JRuby discussion next week in Oslo, do drop me a note at the address in the upper right.

Deploying, Monitoring and Troubleshooting Rails on JRuby

2010-08-30T17:06:52+00:00

I am pleased that my Engine Yard webinar on JRuby and deployment is available for general viewing. While the JRuby deployment story is still evolving and maturing, and the 60 minute time frame is too short to cover the issues in depth, I hope you’ll find the content at least gives you some ideas or directions to look.

As always, feel free to contact me with any questions!

Deploying, Monitoring and Troubleshooting Rails on the JVM with JRuby from Engine Yard on Vimeo.

Warbler 1.0

2010-04-06T17:11:17+00:00

It’s past due time to “carry the 1” over and roll over to a 1.0 version of Warbler. This time around, the changes in the codebase are significant enough that I hope you’ll find many past usability issues resolved.

Assemble in-place

The biggest change is that Warbler now creates a war file in place, without an intermediate copy-to-assemble step. Warbler does this using the rubyzip gem, or alternatively using a small Java extension when run under JRuby 1.5 or greater. This should reduce processing and confusion due to the extra copy, which can sometimes get out of sync. The downside is that Warbler cannot be used easily for exploded directory development, though you can always create the war file and unpack it to a staging area.

Simpler extension

Warbler also underwent an internal refactoring that should make extending it much easier. Here’s how you add Warbler tasks to your Rakefile:

require 'warbler'
Warbler::Task.new

In versions prior to 1.0, if there were deploy steps that created new files that didn’t exist at the time the Rakefile was loaded (such as what the asset:packager:build_all task does in the asset_packager plugin), it was tricky to get Warbler to recognize them. No longer -- now the expected Rake configuration should do the trick.

require 'warbler'
Warbler::Task.new
task :war => "asset:packager:build_all"

Bundler support

Another exciting development in the Ruby development world is Bundler, and Warbler 1.0 supports packaging your bundled gems with it. Warbler even creates a .bundle/environment.rb file inside the war file that loads the gems from relative paths to where Warbler puts the gems in the war file.

More configuration

There are a number of new configuration options, so check out the new configuration and see if any are useful to you.

config.gem_home allows you to control the path inside the war file where Warbler will pack your application’s gems. For use with older versions of Bundler or other custom gem vendoring schemes.
config.webinf_files is a file list that can contain multiple files, XML or otherwise. If the files named in this list have .erb extensions, they will be expanded in the same manner as web.xml.

Rails 3 support

JRuby-Rack, the servlet adapter component bundled by Warbler, also received a version bump, and there are no longer any Java libraries included in the Warbler gem, so the two components can be versioned independently. With the release of both Warbler 1.0 and JRuby-Rack 0.9.7, Rails 3 applications can be warbled and deployed seamlessly, often without any additional configuration.

Please continue to send feedback to the JRuby mailing list or the Warbler bug tracker. Enjoy!

JRuby and Rails 3, Sitting in a Tree

2010-02-24T03:58:00+00:00

Synopsis

jruby -S rails new myapp -m http://jruby.org/rails3.rb

When creating your Rails 3 application, just add the JRuby-specific template (-m http://jruby.org/rails3.rb).

Details

$ jruby -S gem install rails --pre --no-rdoc --no-ri
Due to a rubygems bug, you must uninstall all older versions of bundler for 0.9 to work
Successfully installed i18n-0.3.3
Successfully installed tzinfo-0.3.16
Successfully installed builder-2.1.2
Successfully installed memcache-client-1.7.8
Successfully installed activesupport-3.0.0.beta
Successfully installed activemodel-3.0.0.beta
Successfully installed rack-1.1.0
Successfully installed rack-test-0.5.3
Successfully installed rack-mount-0.4.7
Successfully installed abstract-1.0.0
Successfully installed erubis-2.6.5
Successfully installed actionpack-3.0.0.beta
Successfully installed arel-0.2.1
Successfully installed activerecord-3.0.0.beta
Successfully installed activeresource-3.0.0.beta
Successfully installed mime-types-1.16
Successfully installed mail-2.1.3
Successfully installed text-hyphen-1.0.0
Successfully installed text-format-1.0.0
Successfully installed actionmailer-3.0.0.beta
Successfully installed thor-0.13.3
Successfully installed railties-3.0.0.beta
Successfully installed bundler-0.9.7
Successfully installed rails-3.0.0.beta
24 gems installed

And:

$ jruby -S gem install activerecord-jdbcsqlite3-adapter --no-rdoc --no-ri
Successfully installed activerecord-jdbc-adapter-0.9.3-java
Successfully installed jdbc-sqlite3-3.6.3.054
Successfully installed activerecord-jdbcsqlite3-adapter-0.9.3-java
3 gems installed

Finally:

$ jruby -S rails new myapp -m http://jruby.org/rails3.rb
      create
...(app creation)...
       apply  http://jruby.org/rails3.rb
       apply    http://jruby.org/templates/default.rb
        gsub      Gemfile
         run      jruby script/rails generate jdbc from "."
...(warnings omitted)...
       exist  
      create  config/initializers/jdbc.rb
      create  lib/tasks/jdbc.rake
$ cd myapp
$ jruby script/rails server
...(warnings omitted)...
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-02-23 19:44:26] INFO  WEBrick 1.3.1
[2010-02-23 19:44:26] INFO  ruby 1.8.7 (2010-02-23) [java]
[2010-02-23 19:44:26] INFO  WEBrick::HTTPServer#start: pid=16449 port=3000

Recap

You’ll have best results with JRuby 1.5 snapshots, which include RubyGems 1.3.6. JRuby 1.5 final is coming soon. Also, the new activerecord-jdbc-adapter 0.9.3 release is required for Rails 3 compatibility.

The Rails experience on JRuby continues to get better.

JRuby on Google AppEngine: First Impressions

2009-04-11T04:10:51+00:00

I was surprised by Tuesday’s announcements as much as anyone else. Ola keeps secrets well. He sent me a pull request for jruby-rack just last week mentioning “some restrictive environments where you can’t start threads”. I didn’t blink, and instead just merged his patch.

Despite the surprise news, it turns out my timing wasn’t bad. Just a couple of weeks ago I was experimenting with the Python version of AppEngine, just to see what the fuss is all about. Even though Google’s had its share of criticism for building a platform that is difficult for developers to leave, the lock-in aspect didn’t bother me. I’m a pragmatist first, and I believe that we as developers are the only ones locking ourselves to a platform. We have a choice, after all. And look at all the developers willfully rushing to develop Cocoa applications for the iPhone. The fact that their code is not useful on any other device isn’t stopping them.

The thing with AppEngine is that it’s a unique platform all unto itself. That may seem brutally obvious, but the point seems to be lost in all the frenzy surrounding the Run-Rails-Struts-Spring-Groovy-Grails-Lift-You-Name-It-Framework on AppEngine this week. I’m not saying it’s a bad idea to try to run Rails on AppEngine; quite the contrary. I’m saying you need to be honest about the trade-offs and constraints. And in the case of Ruby and Rails, boy are there a bunch of them:

No regular net/http, restclient, ActiveResource usage. Google has a URL fetch library, and has hooked up Java’s HttpURLConnection to it, but none of the Ruby URL-fetching libraries use it.
No ActiveRecord. ‘Nuff said. For some folks, that’s a welcome change, but wrapping your head around AppEngine’s BigTable-backed data store takes some thought. You just can’t view it like a SQL engine.
No RMagick/ImageScience/attachment_fu. No ImageVoodoo even (no javax.image APIs). Google has it’s own image manipulation API.
Startup/first request processing time is currently an issue. It’s not clear yet how long Google keeps JVMs warm, so if your application is idle, the first few hits to it return 500 errors. I can only assume Google has a plan to address this.
Crypto. Although java.security and javax.crypto APIs are apparently whitelisted, I haven’t had time to figure out how to leverage them. JRuby’s jruby-openssl gem does not work, which means things like digest aren’t available. That’s currently a blocker for Rails’ cookie session store.
1000-files limit per application. In order to work around this, I ended up jarring up all the Rails gems when deploying a Rails application.

These are just a sampling of some of the problems you’re dealing with on the AppEngine frontier. They’re all solvable; it will take a little time and BST (blood, sweat and tears). The point is you can’t expect a Rails application on AppEngine to behave like all the Rails applications you’ve written previously.

In return for your troubles, you get the AppEngine value proposition, which is actually attractive in a lot of ways: Google runs the platform. You don’t have to worry about it. Transparent scaling, monitoring, logging, everything below your application code is taken care of. Single-step deployment, with application versioning and rollback. Scalable services: BigTable storage, memcached, scheduled tasks. My friend Curt Thompson of Best Buy’s Giftag.com talks about how they leverage AppEngine for a non-toy application. (Curt also helped me get my Python AppEngine experiment up and running.)

In the end, I’m still extremely excited about the prospect of using JRuby and Rails on AppEngine, and can’t wait to see what people build with these tools. If you want a little head start, you can check out the first Rails application I deployed, jruby-rack.appspot.com. The “application environment” page is the main dynamic action in the app, which just enumerates a bunch of request and system environment properties so you can get a feel for how things are set up in the AppEngine Java environment. The source code for the application is linked from the front page. Note that the app was deployed with JRuby trunk and JRuby-Rack 0.9.4; Warbler is not yet using these components but you can build them yourself, drop them in and try them. We’ll be updating JRuby, Warbler and other tools soon to make this process more seamless soon. Stay tuned!

JRuby on Rails: Integration Plugin Goes 1.0

2007-03-16T16:55:00+00:00

On the heels of my last post, Robert announced the 1.0 release of Rails Integration, the bits that allow JRuby on Rails to be run out of a Java web archive (war). If you have any interest at all in trying out JRuby on Rails, do yourself a favor and try out the integration bits. Even though this is 1.0, we’re still moving rapidly and would appreciate any and all feedback. (And Robert is doing his best to keep up with changes in core.)

Related to this, Stuart Halloway recently announced his J plugin which is a drop-in collection of Rake tasks that bridge the inherent differences between Rails running on C Ruby vs. JRuby. We still have some work to do in some areas, such as database driver configuration, test database bootstrapping and launching unit tests. For example, instead of the big, ugly, database-specific case statement that’s in Rails’ databases.rake today:

desc "Recreate the test databases from the development structure"
task :clone_structure => [ "db:structure:dump", "db:test:purge" ] do
  abcs = ActiveRecord::Base.configurations
  case abcs["test"]["adapter"]
    when "mysql"
      ActiveRecord::Base.establish_connection(:test)
      ActiveRecord::Base.connection.execute('SET foreign_key_checks = 0')
      IO.readlines("db/#{RAILS_ENV}_structure.sql").join.split("

").each do |table|
        ActiveRecord::Base.connection.execute(table)
      end
    when "postgresql"
      ENV['PGHOST']     = abcs["test"]["host"] if abcs["test"]["host"]
      ENV['PGPORT']     = abcs["test"]["port"].to_s if abcs["test"]["port"]
      ENV['PGPASSWORD'] = abcs["test"]["password"].to_s if abcs["test"]["password"]
      `psql -U "#{abcs["test"]["username"]}" -f db/#{RAILS_ENV}_structure.sql #{abcs["test"]["database"]}`
    when "sqlite", "sqlite3"
      dbfile = abcs["test"]["database"] || abcs["test"]["dbfile"]
      `#{abcs["test"]["adapter"]} #{dbfile} < db/#{RAILS_ENV}_structure.sql`
    when "sqlserver"
      `osql -E -S #{abcs["test"]["host"]} -d #{abcs["test"]["database"]} -i db\#{RAILS_ENV}_structure.sql`
    when "oci", "oracle"
      ActiveRecord::Base.establish_connection(:test)
      IO.readlines("db/#{RAILS_ENV}_structure.sql").join.split(";

").each do |ddl|
        ActiveRecord::Base.connection.execute(ddl)
      end
    when "firebird"
      set_firebird_env(abcs["test"])
      db_string = firebird_db_string(abcs["test"])
      sh "isql -i db/#{RAILS_ENV}_structure.sql #{db_string}"
    else
      raise "Task not supported by '#{abcs["test"]["adapter"]}'"
  end
end

we can use migrations to create the test database:

desc "Recreate the test databases from migrations"
task :migrate_test_db do
  ActiveRecord::Base.establish_connection(ActiveRecord::Base.configurations['test'])
  ActiveRecord::Schema.verbose = t.application.options.trace
  ActiveRecord::Migrator.migrate("db/migrate/")
end

Over time, I hope to see all these efforts coalesce and make the Rails developer experience virtually identical on either interpreter. What would be most excellent is to eventually push some of these improvements back to the Rails core.

JRuby on Rails and ActiveRecord on JDBC

2006-05-15T03:12:00+00:00

Tom and Charlie have just experienced what can only be described as a watershed moment in the grand scheme of dynamic languages on the JVM. The Rails experience may soon be visiting a Java application server near you! Even though JRuby will be in perpetual catch-up mode with C Ruby, Tom and Charlie and the rest of the JRuby contributors have shown incredible perseverance in tracking the Ruby language despite the lack of any formal specification. Maybe Rails will never be mainstream, but the possibilities just got a whole lot more interesting. I agree with Obie that this could be a game-changer.

Now, a few comments about the ActiveRecord JDBC adapter. This code can still be considered alpha quality at best. It’s awesome that Tom and Charlie will be able to demo a top-to-bottom, working Rails app on JRuby, but don’t jump to conclusions yet that this will be anything like a write-once, deploy-to-any-database kind of experience. But you didn’t think it would, did you? We all learned that about Java a long time ago, right?

You can check out the code here. At the moment, I’ve only tried it with MySQL. Most of the problems with it come from the lossy mapping from ActiveRecord’s abstraction of the database to JDBC’s. (Although I suspect as more JDBC drivers are tried that there will eventually be compatibility issues with different implementations of the JDBC spec.)

Probably the thorniest issue is the one of type conversion. ActiveRecord has a fairly simple notion of types: :string, :text, :integer, :float, :datetime etc. Compare this to JDBC’s. What a mess! Right now there are arrays of procs for each AR type that try to guess the best JDBC type to use. This will certainly need improvement to become a more robust solution.

Probably the most promising approach may be to create a patch that refactors much of the AR adapters’ type conversion methods into separate modules that could be included into instances of the JDBC adapter depending on the underlying database. Then the JDBC types wouldn’t be needed at all -- the existing AR database metadata could be reused. Presumably this would require some petitioning of the Rails core team to accept the changes even though the changes don’t buy AR itself any additional flexibility.

If you have a chance to try out the code or can think of any additional tricks that would help the ActiveRecord JDBC implementation along, let me know!

Warbler, A Little Birdie To Introduce Your Rails App To Java

2007-09-04T02:48:40+00:00

This week I was working on integrating the latest JRuby 1.0.1 and Goldspike 1.3 releases into our environment, when my frustration hit a fever pitch.

See, I had always thought that the .war packaging side of Goldspike was a little clunky and un-ruby-like, but I didn’t see a clear path to fixing it. I had heard little complaints about it here and there: the little configuration DSL didn’t give you enough control or wasn’t documented well enough; the fact that it downloads libraries from the internet during assembly (convenient, but not safe or reproducible for production deployments).

Also, in my own opinion it took the wrong approach to packaging Rails in a .war file. It puts the Rails application directory structure into the root of the .war file where any web server or Java application server might mistakenly serve up your code as static content. The Java .war file spec has this special directory called WEB-INF expressly for the purpose of hiding that stuff away, so why not use it?

And then, suddenly Goldspike was packaging up my entire Rails application directory, .svn directories and everything. So I set out to fix this once and for all.

And so I present Warbler. A little bird who chirpily steps up to the task of assembling your Rails application into a Java Web Archive (.war). Here, get it:

gem install warbler

And then, in the top directory of your Rails application,

warble

Those two steps are all it takes to make a .war file, including your application and recent versions of JRuby and Goldspike, that’s deployable to your favorite Java application server.

There are a number of points about Warbler worth mentioning.

Does one thing, well

Warbler only packages, and doesn’t care about anything else, like how to dispatch servlet requests to Rails. This will allow for more runtime servlet binding mechanisms to take advantage of Warbler in the future.

Fast and lightweight

50% less code than the Goldspike packaging plugin, yet does the job quickly and efficiently.

Sane defaults

Warbler only packages code that you need to run the application, omitting database migrations and tests. If your application is self-sufficient (no external dependencies), then the out-of-the-box configuration will probably work for you. Public HTML/images/javascript/stylesheets go in the root of the webapp, where Java webservers expect them to be.

Documented, flexible configuration

Need to customize your configuration? Run warble config and edit config/warble.rb. All the options are there, commented and documented.

Need to change out the bundled JRuby/Goldspike versions? warble pluginize makes a copy of Warbler in the vendor/plugins area of your application, allowing you to change the .jar files in the vendor/plugins/warbler-0.9/lib directory. Warbler then makes his nest in your project’s list of rake tasks (as rake -T | grep war shows)

rake war            # Create trunk.war
rake war:app        # Copy all application files into the .war
rake war:clean      # Clean up the .war file and the staging area
rake war:gems       # Unpack all gems into WEB-INF/gems
rake war:jar        # Run the jar command to create the .war
rake war:java_libs  # Copy all java libraries into the .war
rake war:public     # Copy all public HTML files to the root of the .war
rake war:webxml     # Generate a web.xml file for the webapp

Warbler even omits himself in the .war file produced when running in plugin mode, since you won’t need him at runtime. It’s the little details that matter.

Give him a try and let me know if it makes your life deploying Rails applications to JRuby on Java appservers easier!

JRuby on Rails: Fast Enough

2007-10-25T03:36:00+00:00

People have been asking for a while how fast JRuby runs Rails. (Of course, “fast” has always been a relative term.) We haven’t been quick to answer the question, because frankly we didn’t know. We hadn’t been building real Rails applications on JRuby ourselves yet, and there was no definitive word from the crowd either.

Recently, several guys from ThoughtWorks have been working on a Rails petstore application and benchmark to get to the heart of the matter. Discussion has been heated on the JRuby mailing list, but results have not been conclusive yet.

In the project I’m working on, we’ve committed to using and deploying on JRuby. Eventually we were going to reach the point where we’d need to find out how well our application runs. So today I began running a simple single request benchmark on a relatively busy page. The numbers turned out to be rather surprising:

(The raw data is available here.)

Now, MRI (C Ruby) will always run about the same speed no matter how many runs you give it, but it’s well known that the JVM needs time to warm up. And indeed it does; after 250 iterations, Mongrel running on JRuby finally surpasses MRI. The JRuby/Goldspike/Glassfish combo comes close as well.

Some details about the setup:

I ran the tests on my MacBook Pro Core 2 Duo 2.4 GHz. I didn’t disable one of the cores for the tests, which means that JRuby has an advantage over MRI because it can use both (native threads at work). However, the test script ran the requests serially, which means that the advantage was minimal.
The application is indeed of the “hydra” variety; the setup is nearly identical to the second diagram on that page. So a single request is passing through not one, but two Rails applications in addition to touching the database. It rendered an HTML ERb view with data from an ActiveResource-accessed RESTful service. The applications are based on Rails 1.2.3.
MRI version is using Ruby 1.8.6 and Mongrel 1.0.1.
JRuby Mongrel is also version 1.0.1 (details on installing it here)
JRuby on Glassfish used Glassfish 2 and Goldspike 1.4, deployed in war files via Warbler.
The two JRuby setups used JDK 1.5 and were tweaked to disable ObjectSpace and use the “server” VM (-server argument to the JVM).

The main point I wish to make with these numbers is that JRuby performance is there today, and still has room to grow. There’s no longer any doubt in my mind. Yes, this is a simplistic application benchmark run on a developer’s machine, but it’s a real application. The test may not be exacting in precision, but I see enough in the numbers to believe that this will be replicable to production environments. The plot thickens!