jkraemer.net

Last week, the Medienservice, the platform via which the saxon government publishes its press releases to journalists and to the public, has been relaunched. It now runs on a cluster of JBoss servers that are part of the official saxon e-government platform. While the public web frontend might look like just another Blog-like application to you, I assure you that the stuff that happens in the background is anything but simple - there’s a lot of stuff going on like deferred publishing, publishing press releases only to subscribed journalists, and sending out press releases in four different formats including PDF and XML, to only name a few.

As far as I know this is the first public german JRuby on Rails application - one more reason for me to be proud of being part of the team at webit! that built this baby.

Sorry, but I can’t think of any other reason why Graeme Rocher might write such crap.

Among the points he makes when trying to convince his readers why they should choose Grails over Rails, there are at most two or three which are somewhat reasonable, namely those dealing with integrating your application with external J2EE based services. I completely agree that these are valid points when comparing Grails running inside a fully-fledged J2EE container to Rails running in, say, Mongrel. But since Rails runs fine in a J2EE environment as well, that’s an unfair and misleading comparison.

Using container-managed database connections via JNDI in a JRuby on Rails web app is no problem at all, neither is using Quartz to schedule Rails background jobs, just to name a few examples. I don’t see anything stopping people from using the whole range of J2EE container features in their JRuby/Rails applications once they need to do so.

The whole ‘Grails is more enterprisey than Rails’ argumentation falls apart once you stop comparing apples to oranges, and slap JRuby + Rails onto that damn app server.

Grails 1.0 coming out within the month

Uh cool, yeah. Until now I thought statements like this were more a specialty of closed source vendors trying to convince their potential clients not to check out the competition. Looks like they can’t wait to finally attach that decision maker friendly 1.0 label to Grails ;-)

Anyway, I feel we’re all going to have an interesting time in the future watching how the competition between JRuby/Rails and Groovy/Grails goes on. After all, competition tends to lead to better products in the end.

As promised earlier, here’s the first of several articles I’m planning to write about running Rails on JRuby. Originially I wanted to start this little series with some kind of ‘getting started with JRuby on Rails’ guide. Since I didn’t find the time (or, say, motivation) to write one for weeks now, I decided to skip right through to some more advanced topics. So for this post, I’m assuming you already got your hello world JRuby on Rails project up and running and deployed to the application server of your choice. If this is not the case, have a look in the Wiki for documentation about getting started. It’s also worth following the various relevant blogs, as well as the jruby and jruby-extras mailing lists.

Ok, this post is titled Job scheduling with JRuby and Rails for a reason, so let’s get started with this now.

While Rails itself nowadays runs quite flawless inside application servers like JBoss or Glassfish, the usual way to handle background job (push it to some external daemon) doesn’t fit a J2EE application server environment particularly well. Besides the fact that I couldn’t think of an easy way to get BackgrounDrb running from my application’s WAR file, it simply doesn’t feel right to have any extra daemons like BackgrounDRb running besides that fat application server.

As it turns out, there are several ways to do better.

The GoldSpike solution

The kind folks from the jruby-extras team provide two servlets, RailsTaskServlet, and RailsPeriodicalTaskServlet as part of the GoldSpike plugin. These servlets can be used to run arbitrary Ruby code inside the context of your Rails application either once or periodically every n seconds. To schedule a job running YourJobClass.do_stuff every minute, you would place the following declaration into your web.xml:

<servlet>
  <servlet-name>periodicalTask</servlet-name>
  <servlet-class>org.jruby.webapp.RailsPeriodicalTaskServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
  <init-param>
    <param-name>interval</param-name>
    <param-value>60</param-value>
    <param-name>script</param-name>
    <param-value>YourJobClass.do_stuff</param-value>
  </init-param>
</servlet>

Oh the joy of XML configuration files ;-)

While this works great, I had to run a job not every some seconds, but once a week on a defined day and time. Besides that, declaring a separate servlet for each single background job seems like overkill. Back from my Java days I knew that the Quartz library provided exactly what I needed - support for cron patterns. So the challenge was to get Quartz run my Ruby script inside the context of my application.

The rails_quartz plugin

Our target platform was JBoss, which already includes the Quartz library. I’m not sure about other app servers, if yours doesn’t have this already, just download quartz and put the jar including any dependencies somewhere in your application so it ends up inside the WEB-INF/lib folder of your WAR file. With Warbler, which is my preferred way to package JRuby on Rails applications, RAILS_ROOT/lib is good place, since it will pick up any jars from there automatically.

How does it work?

The plugin provides a ContextListener, which, when declared in web.xml, looks for any job declarations and tells the Quartz Scheduler about them. Here’s an example web.xml snippet scheduling a job to run every friday at 10 am:

<context-param>
  <param-name>yourJobCommand</param-name>
  <param-value>YourJobClass.do_stuff</param-value>
</context-param>
<context-param>
  <param-name>yourJobCronPattern</param-name>
  <param-value>0 0 10 ? * 6</param-value>
</context-param>

<listener>
  <listener-class>org.jruby.webapp.quartz.QuartzContextListener</listener-class>
</listener>

As you see, I use context parameters to configure the command to run, and the cron pattern to use. You can declare any number of jobs you want, just stick to the naming scheme for the parameters: <jobName>Command and <jobName>CronPattern so the listener can find out which pattern belongs to which job.

You can get the plugin here: https://projects.jkraemer.net/svn/plugins/jruby/quartz_rails/ . As always, any feedback is welcome.

As I wrote earlier, I got pretty excited about JRuby and especially about the idea of running Rails on top of it at RailsConf Europe. By pure coincidence we had just had started a project at webit! at this time which had to be deployed to the customer’s J2EE infrastructure. I didn’t really follow the JRuby development before, and therefore greatly underestimated its level of maturity. So, looking for a Rails-like way to build this application, I decided to go with the Groovy-based Grails framework.

At first Grails looks and feels much like Rails, however if you look closer and actually try to build a real application with it, the differences start showing up. Don’t get me wrong, when compared to the more traditional J2EE ways to build web applications (my experiences in this field range from plain Servlets to Struts and Spring), Grails is a huge step into into the right direction. Unfortunately for me, coming from Rails, it just didn’t feel right or complete in many places. Partly this is for sure because Grails, despite its name, is not just a Rails clone, but does things in its own way in many places. Without going into much more detail here, things often weren’t working the way I expected, and documentation was often outdated or missing.

Another issue with Grails for me was Hibernate, its persistence layer of choice. I simply can’t get used to the way Hibernate works. In my opinion it abstracts way too much from the database with its own query language and all its object oriented query building glory. Also it seemed to queue up sql statements and execute them at will at some later time, which I found irritating to say the least. I really don’t understand why Hibernate is the persistence framework of choice in so many J2EE projects. On the other hand it fits the ugly picture of the bloated J2EE web application quite well ;-)

To summarize this rant, don’t underestimate the learning curve of Grails, which will be even steeper when you aren’t already used to Hibernate. I think Rails people having to do J2EE development are just not the target audience of Grails. But it might be a good fit for J2EE developers who either already have their Hibernate models in place or at least have the will to invest some serious time in learning Hibernate.

After all, as you might already have guessed, I decided to start from scratch with JRuby and Rails after RailsConf Europe. And it really felt like coming home from a long and exhausting trip. Despite the lost time in the beginning we met our deadline and had a really great time solving problems the Rails way and deploying to JBoss every now and then. Right now I’m in the middle of my second JRuby on Rails project, same customer, same target platform. I plan to write some more articles about our experiences with JRuby, so stay tuned.