JBoss Application Server (AS) 7 is due for release in early June. We can expect much faster load time, and a leap forward towards JEE 6 compatibility. I work in Red Hat JBoss support, with intimate knowledge of JBoss Enterprise Application Server 5. We were introduced to JBoss AS 7 by Stuart Douglas, who is a lead developer, working on the JBoss AS 7 development team. This a brief overview of the things we learned about JBoss AS7, and one of JEE 6's key features Context Dependancy Injection, or CDI.

CDI and it's JBoss implementation, Weld

The Context Dependency Injection (CDI) part of the Java Enterprise Edition (JEE) 6 specification is implemented by Weld on JBoss AS 7. Anyone who has used JBoss Seam will have a head start learning CDI. CDI is a product of the JSR-299 specification, who's lead is Gavin King, [1]. CDI and Weld allow us to easily use objects from the business layer of an application, in the presentation layer. Previously programmers were forced to save the state of the their business objects in the HTTP Session between server requests, to maintain state between HTTP Requests. CDI leverages the strengths of the HTTP protocol, and Java Server Faces, and hides the complexity of the implementation in the application server (JBoss) logic.

Dependency Injection (DI) has already been used for many years in Java programming. However developers have had to rely on frameworks like Spring in order to achieve it. EJB does provide ways to inject objects, but no way to limit the scope of those objects. CDI provides a DI framework, like spring, with a wider variety of scopes, such as the Request, and Conversation scopes. Leveraging DI, while saving web developers the trouble of managing the scope of the business objects between HTTP Requests.

Anyone who is familiar with Seam 2 will understand the Request and Conversation scopes. The request scope is analogous to a HTTP Request, objects that are created within this scope survive only for a single HTTP Request, so will not be available on the next page, after a redirect. A Conversation scope is longer than a Request Scope, but often shorter than the Session scope. In CDI, a programmer has to decide when a conversation will begin and end. The conversation scope allows a programmer to keep objects alive across multiple web requests, such as during a shopping cart page flow, but avoid having to use a HTTP Cookie, or the Session object directly to store the object. For an in depth, discussion on these scopes, you should read Seam in Action, by Dan Allen [2]. While this book is about Seam 2, the concepts are relevant to CDI and Weld.

Another added benefit of CDI is Type Safety of DI. In Seam 2, and JSF Managed Beans, which object to inject was decided based on a String representation. In CDI, the object type is used to lookup injected beans in the container. For example in Seam 2:

@Name("myBean")

public class MyBean{

     ...

}

It is possible to compile a class which injects 'myBean' into a String like like:

@In

private String myBean

This will compile OK, but at runtime will fail, because the property 'myBean', is not of type 'MyBean'

However in CDI, this will fail at compile time, allowing the programmer to notice the problem sooner, and also the Integrated Development Environment (IDE), to notify the programmer of the issue.

CDI and Weld have merged presentation, and business logic layers of an application together. Now we can easily assess our business logic in the presentation layer, without having to use the HTTP Session directly to maintain state on the server.

Performance Improvements

One of the big advantages JBoss AS 7 has over previous versions is the startup time. JBoss Enterprise Application Platform EAP 5, on the average 2.5 GHZ, 3 GB machine, would take about 30 - 60 seconds to load, without any applications installed. This was a real pain in the neck for any developer bootstrapping JBoss during a project build. You will be happy to know that AS 7 takes as little as 6 seconds to start on the same machine. AS 7 achieves this superior speed through Modular Classloading, and the Modular Service Container.

Module Classloading is a new approach to classloading from previous versions of JBoss. One of the main areas of frustration for a developer trying to migrate between application servers is the that the application servers handle classloading differently from each other. JBoss, as of AS 7 strictly enforces which classes are available to deployed applications. While JBoss allows deployed applications to access the API's it provides, such as CDI, it does not expose it's dependencies. You can read detailed information about the AS 7 classloader in this community article by Jason Greene, [3]. Another feature of AS 7, is that it will automatically filter out libraries from your application which conflict with those provided by the application server, see this article for more information about that, [4] This will avoid many problems with classloader conflicts, because you have to explicitly allow deployed applications to see, and use JBoss' dependencies. Modular classloading makes the lookup of dependencies simpler, because the scope of available classloaders is more narrowly defined. In previous version of JBoss a scan of the application server's classpath happened every time you loaded a new class, in the new classloading model class dependancies are resolved using a simple hashmap, greatly increasing it's speed and efficiency.

The Modular Service Container (MSC) is a complete rewrite of the JBoss Microcontainer used in EAP 5. JBoss provides many JEE 6 services to application developers, and also uses those services for it's internal functions. While previous versions of JBoss provided a way to resolve dependancies between services, MSC has added extra features to resolve and load services dynamically. In AS 7, when you deploy an application that has a dependency on a service, such as CDI, and CDI, has not already be started by JBoss, it will start that service dynamically. Similarly when you remove that same application, and JBoss detects that there are no other applications, or services that require CDI, JBoss will stop it. Previous versions of JBoss where more resource intensive, because it loaded all available services, whether you needed them in your applications or not, and you had to do a lot of work to remove services, see the Slimming guide for JBoss 5, [5]. This fine-grained approach to slimming AS 7 will no longer be required, because JBoss is now capable of dynamically detecting and resolving dependancies to it's services.

Module classloading and the MSC, dramatically reduce the startup time of JBoss. This will allow developers to  run an integration test suite against JBoss in far less time, and improve their productivity. The dynamic dependancy resolution of the MSC means that application administrators will need less intimate knowledge of JBoss to reduce the memory footprint, and disk space required to run JBoss.

Easy Configuration

Previous versions of JBoss EAP spread configuration of it's components across many files. JBoss AS 7 provides a single file for configuration. The current version of the Enterprise edition, EAP 5 provided twiddle, as a command line interface to JMX MBeans, to control the server from the command line. JBoss AS 7 will make the command line, and a Java API, the primary way to make configuration changes on the server. It's command line interface offers tab completion, and extensive array of commands that allow you to remotely manage and monitor the server, and deployed applications.

JBoss AS 7 comes with a new way to manage a JBoss cluster. While previous releases required server configurations changes be manually propagated to each node in the cluster, the AS 7, domain mode automates the task of makes changes to all nodes in a cluster. Domain mode starts 3 Java processes, one JBoss instance, a host process, and process controller. One node in the cluster will be the master node, and it is responsibly for pushing configuration changes, and deployed applications out to all nodes in the cluster. It has various smarts to group nodes, thereby isolating them from other cluster nodes.

In this article I have covered some of the key features of JBoss Application Server 7. The features I covered where the JEE 6 specifications CDI's implementation called Weld, AS 7's performance improvements, and it's new easier configuration model. Many people who work in Java Web Development will be pleased to learn that JBoss understands Request and Conversational scopes, and can feel liberated programming against the CDI specification, because it allows them to move to a different application server in future, preventing the dreaded vendor lock in. I hope you have found this article useful to learn more about what is in the pipeline for JBoss. Red Hat is very excited about using these features in future releases of EAP.

Jason Shepherd

Red Hat Middleware Support Engineer

JBoss 5 Certified Enterprise Application Administrator

Spring 2.5 Certified Professional

Java SE 6 Certified Professional

[1] http://www.jcp.org/en/jsr/detail?id=299

[2] Seam In Action, Dan Allen, 2008, http://www.manning.com/dallen/

[3] http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide

[4] https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7

[5] http://community.jboss.org/wiki/JBoss5xTuningSlimming