In order to deploy a Rails app, I've had to learn the innards of Microcontainer's deployer framework. After a few wrong turns, I feel like I've finally gotten a handle on it.

While we're all used to dropping in an .ear or a .war, and might think in terms of deploying these archive formats, that's ultimately one step removed from true deployment through MC.

Within MC, when you deploy a .war or an exploded WAR directory, the first step is something recognizes that the chunk you're deploying is roughly shaped like a WAR. I'll address that phase of deployment in a future post.

Knowing that the deployment is a WAR also tells MC to look in WEB-INF/ for meta-data descriptors, such as web.xml and jboss-web.xml. This is where true deployment of components starts. Deployment runs through a series of stages, with deployers setup to match particular files and stages, doing the right things at the right time.

One of the earliest stages is the PARSE stage. A deployer can be bound to this stage to be given an early chance to match, parse, and act upon any meta-data file. For normal WAR deployment, the WebAppParsingDeployer does exactly that. There's a nice hierarchy of classes to make parsing XML descriptors such as web.xml super simple.

The WebAppParsingDeployer is the bridge from a web.xml file sitting on the filesystem or in an archive to the MetaData deployment bits. The parser reads web.xml, and produces a WebMetaData object associated with the deployment. The WebMetaData is simply a nice object-tree representing anything you can denote in web.xml.

We also might have a jboss-web.xml meta-data in our WAR, and that is parsed during the PARSE stage by the JBossWebAppParsingDeployer. This deployer, like the previous, reads the XML file and creates, in this case, a JBossWebMetaData object.

Once we've parsed these .xml files, the container has enough information to build up the classpath for the component. Some of these deployers have also thrown off or modified some ClassLoadingMetaData, which describe paths that should be added to the classpath.

As the container enters the CLASSLOADER stage of deployment, other magic occurs to actually set up the classpath.

In the end, it's the JBossWebMetaData that drives the ultimate deployment, but what if we don't have a jboss-web.xml? That's where the MergedJBossWebMetaDataDeployer comes in. It looks for a WebMetaData, and a JBossWebMetaData if one has been parsed, and merges them into a singular JBossWebMetaData. I think it also mixes in any defaults that you have set for server-wide settings.

Additionally, as jboss-web.xml is parsed by JBossWebAppParsingDeployer, it will perform the merge itself. Additionally, magic is occuring to merge any annotation-based meta-data.

I'm a little fuzzy on the ins and outs of the CLASSLOADER stage at this point, but magic occurs there.

And our app still isn't deployed yet. But we're getting there.

Finally, we enter the REAL stage of deployment, which fittingly-enough, is where the actual deployment occurs. Hooray!

Our TomcatDeployer is hanging out there, waiting for JBossWebMetaData objects to appear. When it sees one, it goes to work setting up information for Tomcat to deploy a web-app. It configures everything in Tomcat from the information other deployers figured out from web.xml and jboss-web.xml and embodied in the MetaData.

It jams it into Tomcat, hits the big red "go" button, and port 8080 is serving you web-app.

Finally.

In general, to deploy in AS5 using Microcontainer, you need some MetaData bits, and perhaps a bag of files/classes/resources. Nothing says they have to be bundled into a .war, or include some j2ee XML deployment descriptor. If you have other magical ways of bundling MetaData and resources, you're good to go.

Of course, Ales or Adrian may tell me I'm completely wrong. That's always a possibility. In fact, I'm sure I've got some things wrong, in reverse order, and otherwise mixed-up.

Here's a picture for you, though.

Update:

While discussing this on the Microcontainer user's forum, I discovered that there are indeed several errors and inconsistencies in the above.

Update #2:

New image, slightly new text to match the image better. Comments and clarifications still welcomed.

I woke up and noticed that a memcached mode was announced by Bela Ban, the fantastically Swiss man who jogs waaay too much.

There's a lot of things in this world that can take advantage of memcached. Personally, I find this quite interesting, considering that memcached tends to be the cache-of-choice for lots of non-Java languages. For instance, fragment caching and model caching in Rails supports talking to memcached.

Or now, JGroups.

For those of you playing along at home, I've added jboss-deployers to my GitHub mirror set. Like the others, the 'vendor' branch is the one you want.

• jboss-deployers
• jbossas
• microcontainer
• vfs

I'm adding JBoss projects to my mirror set as I trip across the need to browse their source. If there's a JBoss project you'd like to see mirrored out of SVN, drop the URL to the trunk of the SVN repository in a comment on this post, and I'll start slurping it.

Back in May, I was a manager.

I feebly attempted to direct 8 great guys and gals to further the goals of JBoss.org. After the Codehaus, you'd think I'd be able to help build an opensource community with fun and flair. But I came to realize that it's hard to build a community as an active effort. Instead, I think community develops as a by-product of a useful and well-run project. And that's under the control of the project leaders and contributors, not necessarily some external third party.

Back in May, I gave up being a manger.

Now, the day after Labor Day, fittingly enough, I'll be jumping back into the world of JBoss. But not as a manager. When I was burned out and felt like resigning, Mark Proctor and Sacha Labourey instead talked me into taking a sabbatical. And I'm truly grateful to them. Now, after unwinding for a few months, I asked to rejoin the team as an engineer. Through Sacha's patience and budget manipulation, I'm once again excited to go to work. I think JBoss should definitely be held up as a company that takes care of its people. They could've easily given me the boot, but instead they've been extremely kind and accommodating.

So, what will I be doing?

After talking to Java developers and Rubyists alike, my first goals are to look at Rails as just-another-way to write J2EE apps (or "JEE" I reckon, these days...). Yes, I know about (and plan to use) things like Warbler and JRuby-Rack. Both are good things.

But I also have full control of the deployment environment, to build a stack to make it happier than "build and deploy a WAR".

Through the miracle of AS5 built on JBossMicrocontainer, along with the awesome VFS bits, it should be possible to deploy a Rails app in-situ, right from your working directory. There should be no reason to have to build a WAR while you're hacking a rails app. And deployment to a server should still involve capistrano (in my opinion). Stick to the Rails way of doing things, but make it Java under the covers.

Various blog posts have shown Rails apps on Glassfish in 12, 10, or 5 steps. My goal is to get it down to 1 step. And you should magically be able to pick up and use all the wonderful JEE bits that maps to the Rails functionality the Railers of the world enjoy, without having to be aware of the JEE bits.

Speaking with Mark Newton (the guy who runs JBoss.org now), it seems sensible to view Rails as simply yet-another-programming-model for writing Java apps. The idea is to avoid leaky abstractions, so we're not having to write some psuedo RubyJava application.

Once we've got that base covered, then we can make fun and exciting Ruby bindings to all the powerful JBoss tools, such as Drools, ESB, Cache or MQ.

I expect to have a bit of fun with this. More fun than being a manager, certainly.

In addition to the previously-mentioned JRuby mirror from Codehaus SVN to GitHub, I'm now also mirroring:

• JBoss Microcontainer
• JBoss AS5
• JRuby

All are trunk-only mirrors, not picking up branches or tags. Since the JBoss repository path has about 77,000 subversion revisions, and at one point held any and all JBoss software ever written, I have not mirrored it in its entirety. Instead, I've only grabbed http://anonsvn.jboss.org/repos/jbossas/trunk back to revision 77,200. It'll mirror going forward, but the github repository does not include any ancient history.

For those of you playing along at home, the way to fetch just a cauterized "tip" from SVN to a git repository is to mirror as before, but for the initial "git svn fetch" command, add a SVN-style revision range

git svn fetch -r77200:HEAD

For me, at least, trying to fetch the tip revision for the directory resulted in failure. Going back a few revisions, and using a range that includes HEAD worked much better. Then just push to GitHub has normal, and start your rebase/push cronjob.

The JBoss projects are updated from SVN every 15 minutes. But we're updating from the anonymous SVN repository at JBoss, which itself is delayed from the developer repository by some amount of time. So, ultimately, the GitHub mirror should be mostly up-to-date, but could lag behind actual developer commits by up to and hour, I reckon.

If you're wanting to track these repositories using my git mirror, only track the vendor branch. I make no claims about the stability or sanity of the 'master' ref at any point in time. I will make sure 'vendor' exactly matches the Subversion history, though.

Francois, the guy who leads up the support group for JBoss, let us know that his excellent team is expanding even further. If you've got the chops to support customers, write tutorials, and maybe even fix some bugs, JBoss is looking for you.

Two different jobs are available.

There's the SEG position:

Our JBoss Expertise Team consists of J2EE/JEE architects who deliver Developer-to-Developer Assistance as well as Production Technical Support. This team is the connection point between Customers and R&D. As such, you will be in contact with our customers' top developers and architects. You will also assist our front line Support Engineers when dealing with complex issues. Last but not least, your daily contacts with our R&D team will allow you to work with some of the best J2EE/JEE developers in the world. You will also be expected to prepare sample code and write technical tutorials. Therefore, excellent Java coding skills are required. In addition to writing original code, the position requires the ability to read and understand JBoss middleware code. You should also be able to fix bugs and submit features to the JBoss code base if time and interest allow.

And the Senior TSE position:

You will experience every day how we do support differently, by working hand-in-hand with our team of Middleware Support Experts as well as with R&D and Engineering. This day-to-day cooperation will offer a great opportunity to learn beyond regular training. Primary responsibilities will include providing Production Technical Support as well as Developer-to-Developer Assistance for the JBoss and MetaMatrix products. This position offers the opportunity to support enterprise Java applications delivering middleware solutions to customers of all sizes. It is a very fast paced position offering nearly endless learning and growth opportunities.

If this sounds like a good opportunity for you, head over to the Red Hat careers page. This is a chance to see many of the JBoss enterprise middleware projects used by a variety of customers in a stunning array of configurations and deployments.

Note: The careers page does not yet have a listing for these openings. They should be posted by Monday, so that gives you time to brush up your resume and make it sparkle.

Tonight, the fine folks on the JBoss.org team managed to reach a significant milestone. In fact, JBoss.org is now actually hosted at http://jboss.org/. Imagine that! We'd been satisfied living at http://labs.jboss.com/ for quite a while, so this is a nice change.

Additionally, http://wiki.jboss.org/ has been moved off the old Nukes wiki and onto a more modern wiki. Along with being merged with the wiki that used to live at http://labs.jboss.com/wiki. Like many organizations, we'd ended up with too many. We probably still have too many. But now we have one fewer. You can thank Tomek for that.

Probably the coolest bit of tonight's update is the new feeds subsystem created by Adam. You can check it out, and notice that you can now submit a blog for inclusion in our aggregator. Project leads have more control over their project's aggregator, and we're archiving everything we touch, now.

Today is the day to make sure you've filed your GSoC application if you're a student hoping to participate in this year's Google Summer of Code.

We've got our ideas page up still, or feel free to invent some great project of your own related to JBoss. We're open to new ideas.

Just a couple of quick notes:

Max and the JBoss Tools team have released version 2.01. What I personally find exciting is that this release sees bundles for OSX. The JBoss Tools project is what ultimately feeds into the JBoss Developer Studio, so you know it's good stuff.

Also, Tom, Koen and the jBPM team (with the assistance of the .org designers) have published an updated site that includes a fancy new logo and some diagrams to help you get your footing in the world of BPM.

Google selected the combined Fedora+JBoss.org group as a mentoring organization for the Google Summer of Code 2008.

The JBoss guys have started gathering project ideas. If you're hoping to participate in the GSoC, take a look, and maybe you'll see something that'll inspire you.

If you're a student, the GSoC is a great way to spend your summer and get some bonafide open-source work under your belt. While being paid. Plus, you'll get to work with top-shelf Java developers like Manik Surtani, Ales Justin and Tim Fox, amongst others.

So, get thinking about your projects, because the student application window is about to open.