JBoss 4.0 is remarkable in a number of ways. Not only is it an open source, platform-independent, full J2EE application server but its installation (on Windows 2000, the OS I tested it on) is ridiculously simple.
JBoss includes a Web server (servlet/JSP container, and HTML server), EJB 2.0 container, integrated Hypersonic 100 percent Java database engine, Java Message Service (JMS), JavaMail, and Java Transaction API/Java Transaction Service (JTA/JTS) transaction support. Earlier versions of JBoss used the Apache Tomcat Web server, but JBoss 4.0 is available in an Apache Tomcat version or a version that uses the embedded Jetty Web server. JBoss 4.0 was released this year about the time of JavaOne. The company refers to this as a development release, appropriate as a test for development code. A production release, suitable for supporting deployed enterprise applications, will be available sometime in the fourth quarter of this year. It adds features such as integrated Java Data Objects (JDO), a revamped version of JMS with multicast clustering capabilities, a full implementation of J2EE 1.4, and distributed transactions.
Installing JBoss 4.0 is easy: Unzip the file and alter a couple of environment variables, and you’re there. I had a small Web application Web Archive (WAR) file that I had been using for JDBC testing. Once JBoss was running, I dropped the WAR into the deployment directory, and the app server hot-deployed it (along with its attendant JDBC driver library). Going from download to running my Web application spanned maybe 10 minutes. JBoss’ Java Management Extensions (JMX) for app server control and configuration come into play once everything is deployed. Resource attributes and configurable parameters can be monitored and modified via Management Beans (MBeans), which are, in turn, controlled from the JBoss Management console. Once my servlet-based application was deployed, JBoss automatically instantiated a deployment MBean, which appeared in the JMX console’s management navigation bar. From that MBean, I could deploy and undeploy the WAR application, as well as view various attributes associated with the application.
Admittedly, the JBoss management console is frugal with its graphical elements, as compared to the consoles of, say, IBM’s WebSphere or BEA’s WebLogic. Nevertheless, the result gets the job done. In addition, since JBoss is open source, you can always extend the console to add whatever bells and whistles you deem necessary.
The cornerstone of JBoss 4.0 is its Aspect-Oriented Programming (AOP) capabilities. When properly implemented, AOP lets you describe similar characteristics (aspects) shared by classes derived from different family trees. In the case of JBoss, the added AOP features have plenty of benefits. At the top of the list is the ability to “inject” behavior into a class without having to alter that class’ source. That allows you to make objects persistent, make object methods “transaction aware,” and even provide a class with multiple inheritance.
JBoss’ AOP framework tackles AOP, using a team of colorfully named concepts such as “interceptor,” “pointcut”, and “introduction”. An interceptor is code that intercepts calls made into an object of an intercepted class. JBoss allows you to define interceptors that are hooked into method invocations (constructor methods as well as standard methods) and field accesses. The points within a class at which an interceptor is inserted are defined by a pointcut, which is XML code found in a specific .XML file that is hot-deployed just like the aforementioned WAR file.
A pointcut definition specifies both the intercepted and intercepting class, and it can optionally be fine-tuned (using filter elements described in the XML) so that only specific fields and methods are intercepted. The intercepting class implements an invoke()method, which is called by the JBoss AOP framework whenever a method or field of the intercepted class is accessed. The result is that the interceptor is invisibly inserted between the “outside world” and the intercepted class.
JBoss accomplishes this magic by instrumenting the intercepted class’ class file at load time. When an intercepted class file is loaded, the ClassLoader judiciously “sprinkles” additional bytecode throughout the class file. The bytecode transfers control to a manager class after execution and acts as a sort of switching station, routing interceptions to the correct handling class.
JBoss 4.0’s new AOP framework goes beyond simply injecting new behavior into a class. JBoss provides the concept of an introduction, which is a special sort of interception that rams a new interface into a class at load time. In addition, an introduction can provide an implementation class of the interface (the implementation class is referred to as a “mixin”). The result amounts to multiple-inheritance in Java.
And if sneaking in multiple-inheritance weren’t enough, JBoss also employs AOP to associate meta data with classes and class methods. In essence, JBoss is seeking to mimic the meta data capabilities of JSR-175. It’s likely that JBoss will soon be able to invisibly add all the persistence and transaction management capabilities to plain old Java objects, an action that would otherwise require conjuring up EJBs.
If AOP’s features sound intriguing, but you’re unwilling to battle your way through an application server just to experience them, then you’ll be happy to discover that the AOP framework is available as a separate download from jboss.org.
Complex, but eminently useful
I must confess some initial uneasiness about JBoss’s AOP. It is very similar to the sort of “under the covers” class file manipulation performed by such systems as the OO database FastObjects, and I have a great deal of respect for FastObjects. JBoss’s AOP is simultaneously more elegant — and more disturbing. It instruments at class load time, so there is no explicit, post-compilation step. In so doing, a Java class is injected with behavior that is nowhere apparent in the source code.
I can overcome this uneasiness when I weigh it against JBoss’s easy install and how well its hot-deployment of applications works. My only other quibble with the JBoss is its documentation. While free documentation is available on the JBoss site, it seems to be at least a version or two old, and in some places appears to have been written by people who decided they had better things to do than write documentation. This is mitigated by the active forums that JBoss hosts on its site, where I’d warrant you can get just about any question answered.
Besides, what do you want for nothing?