Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Programming Jakarta Struts, 2nd Edition [Electronic resources] - نسخه متنی

Chuck Cavaness

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








16.2 Packaging the Application as a WAR File


Packaging your web applications using
the WAR format is very convenient. The structure is precise, and
because it is specified so carefully, porting your applications
across the various web containers is much easier. The next section
describes the steps that you must perform to package your web
application as a WAR file.


16.2.1 Creating the WAR File


The first
step in packaging your application as a WAR file is to create a root
directory. In most cases, this directory will have the same name as
your web application. For our example, we will create a directory
called storefront.

After deciding how your JSP and HTML pages will be placed within your
application, place them underneath the root directory in their
appropriate subdirectories. For the Storefront example, our directory
structure so far would look like Figure 16-2.


Figure 16-2. The Storefront application directory structure

Figure 16-2 shows 11 subdirectories, 8 of which
contain JSP pages for the application. The
images directory contains images that are used
globally throughout the application, the
stylesheets directory stores cascading
stylesheets for the application, and the include
directory contains files that are included using either a static or
dynamic include.

The next step in setting up the WAR file is to ensure that you have a
WEB-INF directory underneath your root web
application directory. The WEB-INF directory
contains all of the resources that are used internally by the
application. For example, the TLD files for your custom tag libraries
reside in this directory, as does the web deployment descriptor. This
is also where the Struts configuration files belong. No resource
within this directory can be made public outside of the application.

Underneath the WEB-INF directory, create two
subdirectories: one called classes and the other
called lib. The classes
directory should contain all of your utility and servlet classes. The
lib directory should contain the JAR files that
the application depends on.

Once all of the resources for the web application are accounted for
and are inside the appropriate directories, you need to use
Java's archiving tool jar to
package the directories and files. From a command line, change to the
root directory of your web application and use the
jar utility. You need to give the file a
.war extension, like this:

jar cvf storefront.war .

Because you changed to the root directory, the
storefront directory will not be included in the
WAR file. This is fine, because you may want to call the root
directory something else when it's installed. When
you install the web application, if you plan to explode the WAR file,
all you need to do is create a directory and
un-jar the files, like this:

C:\tomcat\webapps>mkdir storefront
C:\tomcat\webapps>cp storefront.war storefront
C:\tomcat\webapps>cd storefront
C:\tomcat\webapps\storefront>jar xf storefront.war

The location where the WAR file gets expanded is container-dependent.
If you plan to distribute the WAR file without exploding it, all you
have to do is place it in the appropriate place for the container.
You don't have to recreate the
storefront directory, although you might want to
delete the existing directory when deploying a newer version.


Although Section 9.8 of the 2.3 Servlet specification is a little
ambiguous about replacing a web application without restarting the
server, most containers allow you to drop in a new WAR file or
replace certain files without restarting. There's
always a danger with leaving this feature on in a production
environment; however, while developing the application or debugging a
problem, you'll quickly learn to appreciate this
functionality. In containers that do support this feature,
there's usually a way to disable it when you deploy
a web application into production.


    / 181