Due to the success of the JBoss Rails thesis, we're taking the next step. Since it has outgrown its original name, doing way more than just Rails compatibility, we're renaming the project to TorqueBox.
And giving it a logo:
And its own site:
See the announcement over there for more information, including the latest release of the code.
JBoss Rails here at Odd Thesis will be moth-balled, deprecated, but kept around for historical purposes.
After holidays I have worked on some tickets assigned to upcoming JBoss Cloud Beta5 release. Because these are adding some good stuff I will briefly describe what's new.
There was a lot of work done on making JBoss Cloud more EC2 friendly. First of all we added finally appropriate kernel modules for Amazon EC2 XEN kernels (we're using newest ones available — 2.6.21 instead of default 2.6.18). This fixed a lot of errors in messages log and allowed us to run meta-appliance on EC2! You can build JBoss Cloud images directly using our AMI.
Till now we provided only 32 bit images of our appliances. This is over now! We have 64 bit support for all virtualizaton platforms!
There was a lot of work on refactoring, writing new tests (yes, we have some!) and validation rules for config file. You can now hack JBoss Cloud more safely. There is a new rake task added:
rake appliance:APPLIANCE_NAME:validate:dependencies
This task validates additional packages added to appliance definition files. How it is working? It takes all specified repositories and looks if every added package is available in one of them. Simply, but saves a lot of time (you don't need to build appliance to be sure your packages are resolvable). Want to check all available appliances?
rake appliance:all:validate:dependencies
We have also a brand new mod_cluster 1.0.0.CR2 in our appliances.
Uploading packages to remote server is smarter and more fancy — we have a progress bar! Now you know if you should order an espresso or a whole coffee pot.
Signing packages is done also via rake task:
rake rpm:RPM_NAME:sign
It'll sign RPM_NAME package with key specified in your ~/.rpmmacros file. More info will be available in documentation, really soon.
Pssst, I build especially for you some pre-release 64 bit EC2 AMIs: meta-appliance — ami-27ae484e, front-end-appliance — ami-04ae486d and finally back-end-appliance — ami-01ae4868. Grab it!
Be prepared for Beta5 release!
Yesterday I published an article about JBoss Cloud on DZone. Go, check it out, leave some comments, digg it!
After living la vida Ruby for a while, I've grown to love RSpec. It's truly quite flexible, and seems much quicker-to-the-point than JUnit for testing things.
Type-safety is nice and all, but when I'm writing tests, duck-typing is fantastic.
Someone previously had authored the rspec-maven-plugin. But it seemed to sit idle, so I've usurped ownership lately. The plugin, if you don't know, allows you to run RSpec, via JRuby, against your Java code, during the typical mvn test lifecycle phase.
Since I'm doing testing against some hard-core app-server innards, I started tripping over some shortcomings of the plugin. In the process, I've managed to slip another language into the mix.
First, my code deals with JBoss-VFS, which itself mucks about with URL protocol handles to enable nice things like vfsmemory:// URLs and such. But installing these handlers has some fairly strict classloading requirements, namely that they need to be in the system classloader.
So now rspec-maven-plugin forks and sets up your dependencies in the root classloader.
The output during a test-run was sub-par, requiring you to open the HTML test report to really find out how things did.
Now I've added in a console-based progress formatter akin to the JUnit output
[INFO] Running RSpec tests from /Users/bob/oddthesis/jboss-rails/src/test/specs
SPEC: deployers/app_rails_yaml_parsing_deployer_spec.rb
- Java::OrgJbossRailsCoreDeployers::AppRailsYamlParsingDeployer
1 passing; 0 failing; 0 pending
SPEC: deployers/crypto_yaml_parsing_deployer_spec.rb
- Java::OrgJbossRubyEnterpriseCryptoDeployers::CryptoYamlParsingDeployer
1 passing; 0 failing; 0 pending
SPEC: deployers/rails_env_yaml_parsing_deployer_spec.rb
- Java::OrgJbossRailsCoreDeployers::RailsEnvYamlParsingDeployer
1 passing; 0 failing; 0 pending
SPEC: deployers/rails_structure_spec.rb
- Java::OrgJbossRailsCoreDeployers::RailsStructure
0 passing; 0 failing; 1 pending
SPEC: utils/string_utils_spec.rb
- Java::OrgJbossRubyCoreUtil::StringUtils camelize
3 passing; 0 failing; 0 pending
- Java::OrgJbossRubyCoreUtil::StringUtils converting paths to class names
3 passing; 0 failing; 0 pending
- Java::OrgJbossRubyCoreUtil::StringUtils converting paths to class names accomodating namespaces
2 passing; 0 failing; 0 pending
=========================================
TOTAL: 11 passing; 0 failing; 1 pending
You still get the HTML report, of course.
Also, since you like RSpec, you probably dislike Maven grinding away, searching the internet for non-existent POMs, and generally being a time-waster. (If you say "Nexus" I'll punch you in the neck.)
So, after you've run mvn test once, you'll have run-rspecs.sh sitting in your target/ directory. (There's the 3rd language, plain ol' shell). This simply re-creates the fork() and CLASSPATH manipulation before invoking jruby to execute the actual script.
If you want to re-run your tests, quickly, just execute that script:
$ ./target/run-rspecs.sh
If you're futzing around with just a subset of tests, you can pass any normal spec command-line option to it.
This invocation will run only the specs under my test/specs/deployers/ directory:
$ ./target/run-rspecs.sh -p deployers/**_spec.rb
Later, I'll describe how I'm actually writing my RSpec tests to give my JBoss Microcontainer deployers a good thrashing.
To use this, you'll want the latest SNAPSHOT from the Codehaus snapshot repository.
I'm pleased to announce availability of JBoss-Cloud 1.0.0.Beta4 release with Amazon EC2 support.
There are two public JBoss-Cloud AMI's:
You can search also for oddthesis in AMI list, there will be always something fresh in our bucket to run. You can use tool you like to run our images, it could be AWS Management Console or Elasticfox. For more information on running JBoss-Cloud on EC2 refer to this site. For quick setup test we prepared node-info application.
VMware and RAW images are also available for immediately download from our server. Along with EC2 support we fixed several issues, so if you're using VMware it's worth to download this release too!
For command line lovers we have great news: from now it's possible to run and terminate EC2 instances directly from you command line! Just try our new commands (but first prepare your EC2 configuration file):
appliance:APPLIANCE_NAME:ec2:run
appliance:APPLIANCE_NAME:ec2:terminate
As usual, all major changes are listed in our tracking system. Source code is available at GitHub. Feel free to blame us on IRC or mailing-list.
Happy cloud-holidays!
I recently introduced the async task queue functionality of JBoss-Rails. This is where we wire up JMS queues with Ruby handlers from your app.
But what about the client side? How does code outside of the app-server communicate over the queue to the running handler?
Like this stand-alone *.rb script:
#!/usr/bin/env jruby
require RAILS_ROOT + '/client/boot'
JBoss::Client.connect( "oddthesis", "localhost", 1099 ) do |client|
MailerQueue.enqueue( :send_welcome_mail,
:user=>User.find( :first ) )
end
That's it. The JBoss-Rails Support plugin sets up RAILS_ROOT/client/ for you, which includes the handy-dandy boot.rb along with every Java jar that you need to speak JRuby-on-Rails.
So, we require the boot.rb, which sets up the Rails environment along with all the extra JBoss goodness. And then you're ready to write a client.
JBoss::Client.connect(...) is used to connect a client to a running JBoss. Ultimately, this just points to the JNDI service and includes an application name. This is because a lot of apps could be registered with the same naming context. And that context could be located on some other machinery.
The connect(...) method takes a block, which is where you do your client operations. Here, we're sending a task to the MailerQueuer, exactly the same as we would from with a Controller or other code inside the AS.
Here our client is just plucking the first User object it finds in the database, and tossing it to the send_welcome_mail task on the MailerQueue.
In 5 lines of code.
And yes, you can toss ActiveRecord objects across the queue. Let's look at a handler on the far side:
class MailerQueue < JBoss::Queues::BaseQueue
def send_welcome_mail(payload)
user = payload[:user]
deliver_email( user.email_address )
user.welcomed_at = Time.now
user.save!
end
end
The handler, running in a completely separate process (within the AS) has a live AR object it can inspect, update, or destroy.
Not too shabby for a week's work.
I keep having "asynchronous messaging" listed in my presentations as something else "beyond rails" JBoss could bring to the Ruby table. A guy (dude, sorry, I forgot your name) at DevNexus got excited by that idea. So I've been hacking.
Instead of just bridging JMS to Ruby and saying ta-da, I noticed that most folks in the Ruby world currently play with async task queues. Hang out in #github long enough, and you'll see them talking about pausing the queue, restarting the queue, the queue being clogged, etc.
Here, they're using the queue not so much to pass messages, but to trigger a unit of work to be executed outside of the "normal" thread of control.
Sometimes that thread is a web-request, and they queue up an action like forking a repository. Sometimes that thread is a post-commit hook, and they queue up actions such as IRC notifications and other integrations.
Thus, I've started to implement JMS, but so far only exposing it as an asynchronous task-queue.
I'm completely open to suggestions, but my current musings think we want a ruby class per queue.
class PostCommitHookQueue
# I'm a queue!
end
Maybe each queue can accept a handful of different tasks to execute. Let's represent these by methods. Tasks certainly need some parameters, so let's have a payload argument to contain those parameters.
class PostCommitHookQueue
def generate_commit_mail(payload)
# generate an email containing the commit
end
def notify_irc_channels(payload)
# go ping the project's IRC channel
end
end
We create this under app/queues/post_commit_hook_queue.rb, and we're off and running.
But how do we send stuff to it? I'm thinking of a class method enqueue(task, payload).
Here, a client is adding a :generate_commit_mail task to the queue, with a hash of parameters as the payload.
PostCommitHookQueue.enqueue( :generate_commit_mail,
{ :project=>'jboss-rails',
:hash=>872e971ea8 } )
This call is non-blocking, as it's ultimately just sending a message to a JMS destination.
Under the covers, each Ruby queue class ends up deploying an actual JMS queue, which can be administered like any other JMS queue within JBoss.
Once we get this going, I'll look into how we can expose clustered queues, durable queues, and all the other functionality of JMS. But do it nicely using the semantics of this async task queue use-case.
Any thoughts on the design? Any suggested use-cases for one-to-many topics, instead of just one-to-one queues?
Good afternoon everyone. I hope everyone had an enjoyable lunch involving bacon.
Now go grab the latest beta of JBoss-Rails.
The biggest bits in this release are:
Give it a whirl, see if it breaks.
I'm happy to announce JBoss-Cloud 1.0.0.Beta3 release. This release is focused on making JBoss-Cloud more modular, faster and easy to use. Full list of changes you can find here. Below are major changes in this release.
Core of JBoss-Cloud was moved to JBoss-Cloud Support project to give us (and you, obviously), more space to move. Now, if you want to build own appliances, you can use Support project directly. More information available on JBoss-Cloud Support documentation page.
Wizard was completely rewritten. Now it is very useful and user friendly. Major changes are highlighted in my last post on JBoss-Cloud (highly recommended to read). Take a look at the documentation on how to use it.
Documentation for both project, JBoss-Cloud and JBoss-Cloud Support was updated and reflects now all changes. I you want to know more, just check these pages.
If you want to start with JBoss-Cloud immediately please read how to start page.
JBoss-Cloud 1.0.0.Beta3 appliances are available for download here. Source code for 1.0.0.Beta3 is available from GitHub.
Remember, you can always grab latest sources from JBoss-Cloud and JBoss-Cloud Support from GitHub.
We're always looking for your feedback. Meet us in #jboss-cloud IRC channel on freenode. If you want to talk with us on mailing list, feel free to subscribe by sending an email to:
jboss-cloud-subscribe@oddthesis.org
You can search the archives via MarkMail too.
If you have have an idea on how to make our Cloud better (or found a bug) — file a new ticket on Lighthouse.
Next release will be focused on Amazon EC2 support. Subscribe to oddthesis.org for news. You can follow JBoss-Cloud on Twitter too!
JBoss has been selected (along with the Fedora Project) as a mentoring organization for the Google Summer of Code. I've thrown up some ideas on the JBoss idea page.
But don't feel limited to just those. Ultimatley, you, the fantastic, enthusiastic, and intelligent student will write your own proposal to Google. Feel free to color outside the lines and come up with even better ideas for any of the JBoss projects.
If you've got something great, we'll find you a mentor.
Anyhow, if you'd rather hack code than work a "real job" this summer break, start thinking about what you can do with JBoss.
Both the JBoss-Rails and JBoss-Cloud projects look forward to working with some young whipper-snappers this summer.