49Understanding deployment

If you use a script to start the application server, you can always add twiddle state- ments to deploy the desired applications. Two positive notes about this mechanism:

you can use it in the case where the JBoss AS installation directory has been marked as

read-only (because the application isn’t copied to the deploy directory), and you can use it to deploy applications even if the hot deployer has been turned off.

NOTE Astute readers are probably wondering about Java Specification Request 88

(JSR-88), which defines Java EE application deployment. You will be happy

to know that JBoss AS supports JSR-88. But you’ll be unhappy to know that

it has a few problems which prevent us from recommending its use. First,

no tool uses JSR-88; if you want to use JSR-88 to deploy an application, you

have to write code. Second, applications deployed using JSR-88 are placed

into the tmp directory and aren’t redeployed when the application server is restarted. Therefore, you have to redeploy the applications when the application server is restarted.

3.1.2 Understanding application packaging

When you deploy an application, you always deploy the application’s package. A pack-

age can be either an archive file or an exploded directory. An archive is a file such as a

Web Archive (WAR) or Enterprise Archive (EAR) file. But, what is an exploded direc-

tory? Let’s look at an example. Assume you have an application that consists of an EJB

Java Archive (JAR) file and a WAR file containing a web interface. You can package

these files into an EAR file—let’s call it myapp.ear—and copy the myapp.ear file to the

deploy directory. That’s an example of deploying an archive file. Or, you can place the

JAR and WAR files in a directory named myapp.ear and copy the whole myapp.ear

directory to the deploy directory. This is an example of an exploded directory. You

could go even further and unpack the WAR file, the JAR file, or both. Figure 3.1 illus-

trates the files on disk in both deployment scenarios.

You might ask: which is the preferred mechanism? Both have their good and bad sides. With a single archive file, there’s only one file to deal with, and there’s not the pos- sibility of the application being partially deployed because one of the files was deleted (as an example).

There are several advantages to having an exploded directory. First, all the config- uration files and deployment descriptors are in plain view and can be easily edited. If you edit the primary descriptor for an appli- cation, such as the application.xml file

within an EAR, then the hot deployer rede-

ploys the application. Table 3.1 lists the pri- mary descriptors for each application type.

Second, you can change JSPs, style

sheets, and various other text files, and the application automatically starts using them

Deployed as exploded directory Deployed as

archive file

Figure 3.1 Deploying an archive file vs. an exploded directory

(though for a style sheet or image file, the client might have to hit the browser refresh button to see the update). Third, you can easily add new files. For example, you might

have a doc directory that contains PDF files and a servlet that generates a web page of

links to those files based on the contents of the doc directory. Adding a new PDF is

easy: copy it to that directory. The downside to exploded deployment is that you have to contend with multiple files instead of a single file.

One other thing to note: if you deploy an archive file, the deployer unpacks the file into the server/xxx/tmp/deploy directory using a generated name based on the archive filename, such as myapp28562-exp.ear for the previous example. This direc-

tory contains the exploded version of the archive, although any JAR files are left as

they are and aren’t unpacked. Before you think that this is convenient and provides you with the best of both worlds, realize that, when the application server is restarted, most of the contents of the server/xxx/tmp/deploy directory are deleted. Therefore, you should never rely on the contents of anything in the server/xxx/tmp directory. After all, there’s a reason that it’s named tmp!

3.1.3 Understanding application types

As we mentioned in the introduction to this chapter, we use the term application in a

broad manner. So, what is an application? According to Webster, one of the definitions

for application is a use to which something is put. You can infer that to mean that an appli-

cation is any use to which you put the application server, or an application is anything that performs a useful function that you can deploy to the application server.

Two primary types of applications are business applications and services. A business application provides a business function, typically to end users, whereas a service pro-

vides functionality that supports other applications. Often, application is used to refer to

only business applications, but in this chapter, we’ll use application in the general sense. Webster’s definition provides a lot of leeway in what is considered to be an applica-

tion, but that’s good because JBoss AS supports a large number of different applica-

tion types. How does it distinguish between one type of application and another? It uses the suffix for the application’s file or directory name. Table 3.2 lists the various suffixes, describes their purposes, and provides the chapter or section where the application type is covered in more detail.

With so many application types, how does the application server know in which order to deploy them? That’s the question we answer next.

Application type Primary descriptor

WAR WEB-INF/web.xml

EAR META-INF/application.xml

SAR META-INF/jboss-service.xml

JAR META-INF/ejb-jar.xml

RAR META-INF/ra.xml Table 3.1 Primary descriptors for various application types

51