< Zurück | Inhalt | Weiter >

Chapter 23 Deploying EJBs


image

In this chapter we take apart an EAR, put it together, and then send it out into the world.

image



23.1 WHAT YOU WILL LEARN


• What is in an EAR.

• How to build an EAR by hand.

• How to integrate some of the tools we’ve covered before (CVS and Ant) to automate this and avoid having to build an EAR by hand.

• How to deploy an EAR to JBoss.

• How to deploy an EAR to Geronimo.

Some people may wonder why anyone would want to describe to you how to build an EAR by hand. The task of constructing such things is increasingly automated, often performed by IDEs, Ant, or J2EE containers or related tools. So why the grubby details of doing it yourself? Two reasons, really. First, if you


505


hide behind the tool, you never fully understand what is happening. It looks too much like magic, and you’re helpless if the magic fails. Secondly, seeing how it works inside out gives you a better understanding of what is going on and even empowers you to do a custom version for your project. If this discus- sion sounds familiar, it may be because you read something similar about IDEs in Chapter 10.


23.2 LEND ME YOUR EAR: ENTERPRISE PACKAGING AND DEPLOYMENT


There are lots of pieces that are needed to make Enterprise JavaBeans (EJBs) work—not only the classes and interfaces that we have defined, but supporting classes and other Web application pieces (e.g., JSP files) as well. They all have to be in the right place. The distributed nature of EJBs means that we need a way to distribute them across (potentially) several machines. And its not just a matter of putting a single Enterprise JavaBean on a single host. A single bean is typically part of a larger collection of classes and other files (properties, im- ages, JSP, HTML) that work together to make an application. The mechanism to manage all this is the Enterprise Archive, or EAR file.

image

Let’s take a look inside an EAR and examine its pieces. Knowing what it’s made of will make an EAR look less intimidating, but will also help us understand what we’ll need for our application.



TIP

An EAR file (whose name ends with .ear) is nothing more than a JAR file with particular expected contents. So you can easily look inside an EAR with the jar command. Use the -tvf options for table of contents, verbose, and file (meaning that the next argument is the filename).


The budgetpro.ear file will be our example. We haven’t yet discussed building this file, but let’s peek ahead, to see how it will be put together (Example 23.1).

Notice that, at the top level, there are two files and a directory, and inside the directory there are two other files (Table 23.1).

From the standpoint of building an EAR yourself, you need to create all the files listed in Table 23.1 and then put them all together into a JAR file. So we need to understand those pieces.


image

Example 23.1 Contents of a sample EAR file

$ jar -tvf budgetpro.ear

0

Wed

May

19

05:58:02

CDT

2004

META-INF/

110

Wed

May

19

05:58:00

CDT

2004

META-INF/MANIFEST.MF

295

Wed

May

19

05:58:00

CDT

2004

META-INF/application.xml

11498

Wed

May

19

05:58:02

CDT

2004

budgetpro.jar

12626

Wed

May

19

05:58:02

CDT

2004

budgetpro.war

$









Table 23.1 Files inside an EAR archive


image

image

Name budgetpro.jar budgetpro.war MANIFEST.MF


application.xml


META-INF

Type

JAR WAR

text


XML


directory

Content

The EJB-JAR file—the JAR file that contains our EJB. The Web application with servlet and JSP files.

A standard JAR manifest; at a minimum, it gives the version number of the JAR file format—for example, Manifest-Version: 1.0.

The deployment descriptor, an XML description of what’s what.

A directory with other files.


image


The plain files that appear in the META-INF directory are simple. The MANIFEST.MF file is like any JAR manifest and can contain simply the JAR version number:


Manifest-Version: 1.0


The application.xml file is shown in Example 23.2

Two JAR files are mentioned in this XML description file. This tells the container that we have two modules, an EJB and a Web application. The Web module also defines a context root, which is the portion of the URL pathname that is intended to direct requests to this Web application. For example, if your host is www.bighost.com, then the context root of /budgetpro means that the URL you will use to access the Web application in this EAR is www.bighost.com/budgetpro/ followed by whatever other filename you might need to append, such as a JSP file—or, if left blank, the default index.php file.


image

Example 23.2 Sample application.xml file

<?xml version="1.0" encoding="ISO-8859-1"?>


<application>

<display-name>BudgetPro</display-name>

<module>

<web>

<web-uri>budgetpro.war</web-uri>

<context-root>/budgetpro</context-root>

</web>

</module>


<module>

<ejb>budgetpro.jar</ejb>

</module>


</application>


image


That takes care of the two plain files. Let’s also look inside the other two archives, the JAR file and the WAR file, and see what they hold.


 


23.2.1 What’s in an EJB-JAR File

23.2.2 Using Our Bean

23.2.3 Packaging the Servlet

23.3.1 JBoss

23.3.2 Geronimo

23.4.1 Ant and CVS

23.4.2 XDoclet