We just recently released new JBossAS7.0.0.Beta1 (great work guys!):
While I’m not so involved (as with JBossAS5 and JBossAS6) with this new runtime / platform, I do still closely follow what and how things are done. And I must say it’s a real pleasure to work with the new concepts and super easy to add anything new, meaning the good old JBoss user experience [1] is here to stay!
To borrow a saying from my colleague, let’s put the code where the mouth is. So, let me list a few things I did lately to see what could be done with new JBossAS7. Note: this is experimental stuff, and as such no guarantees apply :-)
Back to JBoss2?
As probably some of you remember, JBossAS used to also ship with Jetty as web container. Since I was already working on Weld and Jetty7/8 integration, I started wondering what it would take to have that old web container option again.
And it turned out, as I expected, that having hello-world functionality was really easy to do. But since my goal was to be able to deploy Weld’s Permalink example, it took a bit more work to get JSF and CDI in place. Specially JSF was a bit of an issue, with all the static factories, etc, not to mention the fact I know little about JSF. While CDI integration turned out to be fairly easy, as it wasn’t much different from what I already did for pure Weld servlet integration.
The code is here: https://github.com/alesj/jboss-as/tree/jetty but with JBossAS7 super fast progress it’s already far behind the current upstream master. So rebasing this would not be so trivial. Hence leave it at POC. :-)
Grapher2 strikes back
Another history artifact brought back to life. :-)
This is something I did to inspect MC’s dependencies. But with a bit of refactoring and better OO practice, I easily managed to turn this into generic dependency displaying web app [2].
Since JBossAS7’ new classloading layer is modular, it is probably a good thing to know what some of these dependencies are. And this is where this tool helps you. At the moment I quickly added just two “commands”:
Pull my finger
As already mentioned, the new classloading layer is 100% modular. And looking at JBossAS7 standalone.sh, you can see that the whole app server is actually started as single module, which then pulls in its dependencies and so transitively-forth. So, what about if we only shipped this single jar plus a few descriptor files, making the distribution only (that-jar-size) big?
It turns out this is really easy to do. The whole module loading is left to ModuleLoader class, meaning if we properly implemented this, it would be able to pull our modules remotely.
This is the remote ModuleLoader class that does it:
And this is my experimental distribution -- only 377kb!. :-)
(this pulls modules from googlecode project experimental repo)
With sub-systems and services already being on demand, this is how you can do the same with modules. Also you can simply delete the existing module from your disc, and the remote ModuleLoader will pull it down for you again, making updates sharing really easy.
OK, back to my Weld work now, and onward to 7.0.0.Beta2!
[1] -- as a user (cca 5y ago) I always loved the way you could easily change default AS behavior, or add new things; aka SpringDeployer ;-)
[2] -- yeah, I know, the default layout sucks :-)
