In this chapter, we will complete the standalone server configuration overview by looking at the Web server configuration. JBoss AS ships with an enterprise-ready Web server, designed for medium and large applications, based on the Jakarta Tomcat.
At first, we will learn how to configure static and dynamic resources on the JBoss Web server. We will then explore the structure of a web application by creating, packaging, and deploying a sample AS 7 project. Our sample application will be further enhanced with some other Java EE components including data persistence (JPA), which will ultimately give you the taste of a complete Java EE 6 application.
This section covers the configuration of the Web container as a subsystem of the application server. Historically, the JBoss AS has always been bound to the popular Apache Tomcat engine for rendering web applications.
Inclined to build a profession as JBOSS Developer? Then here you can learn JBoss Training Online.
The new release of JBoss Web is actually based on a fork of Apache Tomcat 7.0, which implements the Servlet 3.0, the JavaServer Pages 2.2 specifications from the Java Community Process and includes a Java Server Faces 2.1 compliant implementation.
On the top of the Web container, additional frameworks can be run, such as the Web service engine, which is based on the Apache CXF framework and helps you build and develop services using frontend programming APIs, such as JAX-WS and JAX-RS.
A standard Tomcat Web server uses a file named server.xml to define the configuration of its services. As we have anticipated at the beginning of this book, the AS 7 configuration is centralized into a single file named
standalone.xml (or domain.xml if you are running a domain), so the Web server configuration is now also contained in this file. Here’s an extract from the “web” subsystem:
As you can see, the default configuration is pretty short as it relies largely on default values. The web subsystem defines a virtual server named “default-host” with a set of aliases (like “localhost”) contained in it. Virtual hosts allow you to group web applications according to the various DNS names by which the machine running JBoss is known.
The most interesting settings are about the Web server connector and its socket-binding interface. The socket-binding element in turn references the socket-binding group, located at the bottom of the configuration file.
A connector is basically a Java object, which provides an interface to Web server clients. The default configuration provides just a quintessential connector configuration, leaving the remaining attributes to default values. That could be just fine for simple applications. However, if you want to configure applications that require a minimum of complexity, you should configure by yourself the connector attributes with the most appropriate values. The following is a connector configuration that shows off all the available connector attributes:
So, when using this configuration, the http connector will use a bounded Thread Pool configuration to serve client requests (Please refer to Chapter 2, Configuring the Application Server for more details about the Thread Pool configuration.)
All the other connector settings refer to the equivalent properties used by Tomcat/earlier JBoss Web server, so we include them next just for your reference:
The protocol parameter deserves a bit more explanation. As a matter of fact, the embedded JBoss Web server is able to listen for incoming connections, using either the standard HTTP Protocol or the Apache JServ Protocol (AJP).
In Chapter 9, Load Balancing Web Applications, we will show what the available options are to configure the Apache – JBoss connectivity. For the moment, let’s see how you can upgrade the default HTTP connector using the Apache Portable Runtime Connector (APR).