Announcement: TorqueBox

18 May 2009

java jboss rails ruby

I announced the TorqueBox project today.

It's the coolest platform for your Ruby applications, ever. Really.

New JBoss-Rails Release & Reminder

03 December 2008

java jboss jruby rails

Just a reminder, in case anyone didn't make the jump..

My Ruby/Rails/JBoss blogging is going on over at Odd Thesis these days.

That includes this announcement about the 1.0.0-Beta-2 release that just popped.

Workblog

10 November 2008

java jbor jboss rails

Just when I've trained my boss to read this blog to keep up with my status, I go and launch another blog, specifically for my workstuff. In addition to blogs about JBoss things, it'll include other documentation for building, installing and using the related projects. The projects are grouped into constellations based around theses. Hence the name:

In addition to being a new blog, it's also my attempt to eat my own dogfood and prove it all works in the Real World.

The Odd Thesis site runs entirely on the JBoss-Rails stack.

I'll still blog random crap here at fnokd, but if you're looking for my JBoss experiments, add the Odd Thesis feed to your reader. I've initially imported appropriate posts and comments from this blog.

Boot up JBoss

16 October 2008

java jboss rails thincrust virtualization vmware

On my path towards clustering a Rails app on JBoss on EC2, I stumbled across Bryan Kearney and the other Thincrust guys. With their help, I now have a JBoss AS5 + jboss-rails "appliance" ready to roll.

Grab the raw image or the VMWare image, and play along at home.

Fire up the image in your favorite virtualization environment. I give my virtual machine at least a gig of RAM. Marvel at the pretty Grub splash screen, courtesy of James Cobb (JBoss.org designer).

Let it boot on up, and you'll notice a handful of things:

  • Very few things roll across during boot. The image is an assembly of "just enough" OS bits.
  • Before JBoss boots, "Installing Appliance" or "Updating Appliance" will scroll by. This is the Thincrust magic that allows adjustment of the appliance in a consistent and controlled manner (via Puppet).
  • JBoss AS 5 (with rails deployer) starts at boot.

You can login with root password of thincrust.

The login prompt will tell you the IP address of the appliance, since it probably booted off DHCP. JBoss will be up and running at http://<IP_ADDRESS>:8080/.

You can su jboss, whose $HOME is /opt/jboss/jboss-as5, which coincidentally is $JBOSS_HOME. The default configuration is used to start the AS. Logs are under /opt/jboss/jboss-as5/server/default/log/. And to deploy, just drop something into /opt/jboss/jboss-as5/server/default/deploy/ and it'll hot-deploy.

To control the service, as root:

  • service jboss stop
  • service jboss start
  • service jboss status

I'll make the RPMs used to build this available sometime soon. Until then, you can poke around the bits I use to create the RPMs ultimately used by Thincrust to build the appliance image. They are packaged in a way that makes my Red Hat brethren throw up in their mouths a little bit.

Also, once I test'em on EC2, I'll throw out public AMIs for testing.

By no means is this complete. This just marked a nice spike of a milestone along the way. There's still plenty of things that'll poke you in the eye if you're not careful. Always wear your safety harness. Drink plenty of fluids. Keep away from children.

JBoR: Will it cluster?

29 September 2008

clustering java jboss jbosscache jruby rails

JBoss on Rails will indeed cluster!

After modifying and dropping my jboss-rails.deployer into an 'all' configured server of JBoss AS 5, and firing up 3 instances on my localhost (non-trivial on OSX...):

  
10:43:28,409 INFO  [RPCManagerImpl] Received new cluster view: [127.0.0.10:63740|2] [127.0.0.10:63740, 127.0.0.11:63747, 127.0.0.12:63749]
10:43:28,435 INFO  [RPCManagerImpl] Cache local address is 127.0.0.12:63749
10:43:28,469 INFO  [ComponentRegistry] JBoss Cache version: JBossCache 'Poblano' 2.2.0.GA

And I've got 3 nodes running the same Rails app, all sharing a cookie and a JBossCache cache. Nick Sieger's JRuby-Rack handles binding the Rails session to the actual servlet session, and JBossCache takes care of the rest.

A little 8-line perl round-robinning load-balancer is wired up through mod_rewrite in my Apache httpd.conf to throw requests to each of the nodes. Anything set in the session is immediately available at the next request which lands at a different node.

Further down the line, we can look at a clustered cache for caching AR models and view fragments. Not too shabby.

It should be fairly easy to create a nice Amazon EC2 AMI with Fedora+AS5+jboss-rails, plus some better Rake/capistrano tasks, and make for quick cluster deployment. Any EC2 experts wanting to jump in?

JBoss Amputation

23 September 2008

java jboss jbossas rails

Since JBoss AS 5 is built on top of Microcontainer, it's effectively a network of beans just doing their respective jobs. You have already probably noticed that it ships with 3 included configurations: minimal, default, and all.

Unfortunately, they're awefully far apart along the spectrum of configuration options. The minimal configuration barely gets the container running, while the all configuration includes, well, everything. For most apps, it's safe to start with the default configuration. But default to who? It's the 80% case. But the 80% of the world who gets by with default, it still probably includes way more than they need. Of course, each user needs a different subset of that 80%.

Given that the MC is managing a graph, it seems like we should be able to actually perform a solve to determine what is or is not required. Or at least get a good idea. Bonus points if someone can then twiddle conf/, deploy/ and deployers/ to tidy things up.

Anyhow, for the jboss-as-rails project, I'm kicking it old-school, and going with default. I'm jamming it into git, and hopefully with some help, we can get it pared down to what we need.

The jboss-as-rails project is simply a configuration of AS that includes only what we need, along with the jboss-rails.deployer from the jboss-rails project (notice the subtle naming difference...).

Here's a picture to see how it'll all ultimately fit together.

The plugin will offer rake tasks for managing the included AS, deploying your app. I'll also produce an AS-free version of the plugin, assuming you want to manage your own AS separately.

And poke around jboss-as-rails, see what we can rip out.

JBoss on Rails

22 September 2008

java jboss jbossas rails ruby

Tomorrow is my first real status update call with my boss, Sacha Labourey. I've been anxious to deliver something, to prove I hadn't gone completely pudding-brained during my tenure as management.

This morning, it all finally came together in a pleasing fashion, causing me to hoot and holler loud enough to scare the cats and probably some cows.

I've just pushed an ugly-but-working deployer targeting JBoss-AS 5.0.0.CR2 (the latest and greatest!)

It's not very consumable at this point, as it's just a deployer, not a nice Rails plugin with a set of Rake tasks. Heck, it doesn't even undeploy yet.

But adding the deployer to your server's deployers/ directory allows you symlink live RAILS_ROOTs into your deploy/ directory, and be running on JBoss.

Live. In-situ. Edit your controllers or views as you like, and your changes are immediately reflected in the running instance. Just like with ./script/server. It does not even have to redeploy your app. The rails framework is handling the magic reloading.

It's taken me some time to dig through the innards of JBoss-Microcontainer, and a few false starts, but I finally figured out a super simple deployment process.

I'd previously been trying to manipulate a RAILS_ROOT into a synthetic Java WAR archive, and shoe-horn things around that. But I have the freedom to go lower than that, so the jboss-rails deployer just sets up a Catalina context appropriately, without regard to WEB-INF or other non-Rails stuff. There's no need for that cruft. Likewise, I can directly control and manipulate the classpath, so the RAILS_ROOT does not even have to have any JRuby bits in it.

The example application (src/test/ballast) is a virgin rails app with ActiveRecord disabled so I don't have to deal with database-driver gems just yet.

Once deployed, a Rails app looks like pretty much any other web-app. The jboss.rails.deployment domain contains deployment objects for each rails app. And jboss.web contains all the webby bits floating around.

I need to go back and remove the dead-end code I've left in my wake, and update the tests I'd disabled while in a coding flury (bad Bob!) I plan to put together an easy-to-consume plugin gem which contains an nicely-configured AS along with the jboss-rails deployer pre-installed, along with rake tasks to start/stop AS, and deploy your app. I'd also like to give clustering a whirl, and see what we can do.

It's been an excellent 3 weeks back as an engineer.