My current gig at JBoss is labelled "research and prototyping". That's a relatively open-ended job description, so I've taken to giving myself theses (that's the plural of "thesis") to help direct my work.
These are not academic theses, though; these are open-source projects. I'm truly hoping people find them useful enough to start playing with and ultimately contributing to or leading them.
Want to hear more about JBoss Cloud directly from core developers? Want to know what's the future of JBoss Cloud? Take a seat in one of these locations:
JBoss Cloud is a set of images to run your applications in a JBoss AS 5 cluster in a cloud. It’s virtualization platform independent; you can run it on your favorite platform: Xen, KVM, VMware and of course on Amazon EC! We’re providing a full set of images for both architectures (i386 and x86_64).
After start, JBoss Cloud will automatically form a JBoss AS 5 cluster. No user interaction is required! Just deploy your application and start using it.
Management appliance
We have added a management-appliance. A management appliance is responsible for detecting other running appliances on a network. Actual node list is stored on management appliance. After node discovery is done, management-appliance pushes front-end-appliance address to other nodes. For example if a back-end appliance receives a front-end-appliance address it’ll adjust configuration files and start JBoss AS 5 service. Similar other nodes will configure and start their services.
In case of configuration change, service will be restarted automatically with new settings.
There is no need to start appliances in a specific order, just launch them, they will recognize each other after start. Be sure to launch management-appliance too!
On EC2 you must provide your EC2 credentials as user data to launch management-appliance. If you don't do this it'll boot, but it will not be able to discover other appliances. To inject credentials encode with base64 following string:
access_key: YOUR_ACCESS_KEY
secret_access_key: YOUR_SECRET_ACCESS_KEY
To encode this string you can use for example this page. Passing this data to management-appliance i really simple. If you're using Amazon AWS Management Console, just click Show advanced options and put your encoded string into User Data field.
If you're building management appliance from source. Just run:
rake appliance:management-appliance:ec2:run
I'll automatically inject appropriate data.
Full set of images are now available
Beta5 is the first release with full images stack available for download. Now we provide both, 32 and 64 bit AMIs and packages for other virtualization platforms in both architectures, too. Just grab them and tell us how it feels.
EC2 support improved
AMIs are now running with newest available kernel. Proper modules are also included.
Dependency check before building appliance
For those who want to build own images using rake tasks there is a RPM packages dependency check added. You know if build will succeed before it is started. It’ll save some time in case of creating new images. More info on using this feature you can find in my previous post.
We have also upgraded some packages to newest available versions:
If you're interested in Amazon EC AMIs, just launch these:
i386 architecture:
x86_64 architecture:
In case you're using other virtualization platforms (eg. VMware or KVM) we are providing a set of images. Just grab, unpack and run them!
We're always (almost) on IRC. Just join #jboss-cloud on freenode! Are you feeling in a mailing list better? No problem, send a blank message to jboss-cloud-subscribe@oddthesis.org to subscribe.
Documentation is as always available on documentation page.
TorqueBox, the project formerly known as JBoss-Rails, has just released version 1.0.0.Beta12. Details are available over on the TorqueBox site.
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.
Copyright 2008. Odd Thesis by Bob McWhirter is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.