< Zurück | Inhalt | Weiter >

20.5.4 IDE Integration

Another piece of software you might want to look at is JBoss-IDE,15 an Eclipse plug-in for JBoss. The software is not downloadable from the footnoted Web site, it is available only from the Eclipse Install/Update manager, so run your copy of Eclipse and install it. We will not cover JBoss-IDE here, but if you use Eclipse as your development platform, JBoss-IDE is very useful for managing and deploying EJB’s, servlets, and JSP.


Not to go all Sun-Tzu on you or anything, but if you want to win the war, you must control the initiative. In other words, move only when you are ready. Deploying software into JBoss could not be easier if you get everything ready before you begin.

You see, the key is to create a correctly configured WAR file, as a

build.xml file from our project does (Example 20.6).

If you look at the deploy task, you will see that it simply copies the WAR file to a particular directory under the Web server16 and, it turns out, that is all you need to do to deploy to JBoss. JBoss will notice the new WAR file, stop any existing version, and start the new one. It all depends on getting the WAR file right.


An up-and-coming alternative to JBoss is Apache Geronimo. Part of the Apache Software Foundation’s set of projects, Geronimo is an Open Source, Apache- licensed17 implementation of the J2EE specification. Furthermore, Geronimo aims to be an Open Source J2EE implementation that is J2EE-certified by


15. http://www.jboss.org/developers/projects/jboss/jbosside

16. Note that that’s normal for development. For integration and production, either someone authorized will run the same build on the target, or (more likely) the WAR file will be “formal- ly” built, tagged, and copied to the test or production server. We’ll talk more about that when we get to application maintenance issues.

17. Most notably, it doesn’t require anyone to open the source of their changes or customiza- tions if they improve on an Apache software project, unlike the GPL which does.


Example 20.6 Ant build.xml for the BudgetPro servlet and JSP examples

<!-- ================ File and Directory Names ================= -->

<!-- ...

app.name The name of our application, used for file/dir names. build.home The name of the directory into which the

"compile" target will generate its output. server.home The name of the directory where the Web server

is installed.

deploy.home The name of the directory into which the WAR file will be copied.


<property name="server.home" value="/usr/local/jboss" />

<property name="deploy.home"


<!-- ... -->

<!-- ================ Deploy Target ============================ -->


The "deploy" target copies the WAR file into a location required (i.e., defined) by the servlet container. For some servlet containers, you must restart them before they will recognize our new/modified Web application. Others may reload automatically.


<target name="deploy" depends="compile"

description="Deploy application to servlet container">

<!-- Copy the contents of the build directory -->

<mkdir dir="${deploy.home}"/>

<copy todir="${deploy.home}" file="${app.name}.war"/>


<!-- ... -->

<!-- ================ Product WAR file ========================= -->

<target name="war" depends="compile" description="Create WAR file to be deployed">

<war destfile="${app.name}.war" webxml="web/WEB-INF/web.xml">

<fileset dir="${build.home}"/>




Sun.18 We will take a quick walk through the installation of the Apache Geronimo Java application server. Geronimo not only runs servlets and JSP, but it is also, as we shall see in later chapters, a J2EE EJB container, so the installation part of this chapter is important for using the examples and technologies covered in the remaining chapters.

Geronimo is a complete application server. It provides a full, production- ready, J2EE environment. It is the stated goal of the Geronimo project to pass the Sun J2EE certification tests. Such certification will, in all probability, quickly make Geronimo one of the most widely used J2EE application servers. A great deal of Geronimo information can be found on the Geronimo

Web site.19


As of this writing, the project was just nearing the certification process. Only the milestone releases were available for downloading. By the time you read this, however, a fully certified version will likely be production-ready. There may be slight differences in the download and installation procedures. Be sure to follow the instructions from the Web site and any readme files for the most up-to-date information.


First off, you must choose what form of the product to download. The choice is really between a binary and source distribution. Within that choice, you can choose between two compression methods, zip or tar/gzip. While the first is typical for Windows distributions and the second for Linux, you can choose either, as Linux has utilities for decompressing both. More importantly, the binaries are Java JAR files so they are not tied to a particular operating sys- tem. We will download and install a binary. Just click on the tar.gz filename and save the file.

If you haven’t read the previous sections because you were going to skip JBoss and just use Geronimo, please go back and read Section 20.3. It deals with administration and privileges for setting up your installation, and you’ll want to know that for this chapter’s installation discussion, too.


18. As of this writing, there was still a legal hurdle to overcome, since Sun requires derivative works to be branded and compatible, whereas the Apache license places no such requirements on its derivative works. This may be resolved by the time you are reading this.

19. http://geronimo.apache.org/


20.8 Installing Geronimo 467


Using a platform-neutral system like Java has both advantages and disadvan- tages. A disadvantage is that, generally, Java products don’t use the traditional installation mechanisms of your native platform. For Linux users that means that with Java you don’t install using an RPM or a DEB. But this is somewhat offset by the fact that all a Java application needs is for its classes (in JARs) to be arranged in a particular pattern on the filesystem. In other words, all you need to do to install Geronimo is to unpack the tarball.

You did the hard part already. Since you have created the group and made yourself a member of that group (see Section 20.3), any member of the group can install the product:

$ cd /usr/local

$ tar xzvf geronimo.tar.gz




At this point we suggest using one more Linux filesystem trick. The tarball unpacks into a directory whose name includes the product version—in this case, geronimo-1.0-M1. In many cases, you will want to be able to have more than one version of Geronimo installed on a box simultaneously, either because you need to port projects from one version to another, or perhaps because you need to develop applications that will run on different versions on different target servers. To make your life easier, create a symbolic link to a generically named directory, such as geronimo and have that symlink point to geronimo-1.0-M1. Then you can write your startup and shutdown scripts to use the geronimo pathname. You can then switch to another version by changing where the symlink points:

$ cd /usr/local

$ ln -s geronimo-1.0-M1/ geronimo

This process is discussed in detail in Section 6.2 in the context of switching between Java SDK versions.



Getting the Geronimo server up and running is simply a matter of running a Java application contained in the server.jar file in the bin directory.

$ cd /usr/local/geronimo

$ java -jar bin/server.jar org/apache/geronimo/Server

That last parameter looks like a pathname, but it isn’t. It is a configuration ID which just uses the pathname-like syntax as a namespace, to be unique to Geronimo (by virtue of the /org/apache/geronimo prefix). That name tells the server which of the several possible configurations you want to use. For more information on the other configurations, refer to the Geronimo Wiki.20 Having once invoked a particular configuration, you need not repeat that configuration choice on subsequent invocations. That means that the next time

you run Geronimo, you can just use:

$ java -jar bin/server.jar

If you want to put this in a startup script you’ll want to use the full specification, so as to be absolutely sure what you are getting.

To stop the server invoked from a command line, simply type Control-C. If the server was invoked from a startup script, you will need to find its process ID (e.g., with the ps command) and use the Linux kill command to send it a signal.

20.10 REVIEW

In this chapter we have looked at the installation of both the JBoss and Geronimo Java application servers on a Linux platform. For both of these Open Source servers installation was little more than getting the JAR files in a usable location. We reviewed the System V init system and explained how to add JBoss to the regular system of services on your Linux box. We showed you how to use groups and permissions to enable a number of nonroot users to do the basic application server administration.


20. http://wiki.apache.org/geronimo/


20.12 Resources 469


There is configuration information about your Web applications that must be provided to the Web servers in XML files. A small bit of this will be discussed in Chapter 23, but much of this you will need to find elsewhere. Since this in- formation is in XML and specific to each application server, there is little of it that is specific to the deployment on a Linux system.


Documentation on JBoss is available from JBoss.org. They have an interest- ing business model in that they open-source their code but charge for the doc- umentation. Expect to see more third-party books on JBoss, or you may see a move toward Geronimo instead.

Geronimo is, as of this writing, a bit sparse on documentation, too. There is a Wiki site with the beginnings of documentation. Try and hunt down what you need starting from http://wiki.apache.org/geronimo/ and at the http://geronimo.apache.org/ home page.