You can use a Web Application Archive (WAR) file created from an Ant build script to deploy Java code to a server. A Web application in Java has a certain format located within a special directory named WEB-INF. This directory contains a lib directory for JARs, a classes directory for unpackaged class files, and a Web.xml file describing the application.
The rest of the Web application is just normal HTML, JSP, images, and directories. These can be zipped into a WAR file and then deployed to a server without having to make any modification to the server. Most important, the server will notice when the WAR file is placed in the webapps/directory and will automatically unpack it and add it to the server without changes to the Server.xml file. Deploying a change is a simple matter of overwriting the WAR file with a new one. The server will notice again, unpack it, and reload all class files.
The Ant war task is an extension of the jar task, with some special handling for the WEB-INF directory. The WEB-INF directory may have four subtags:
- · lib
- · classes
- · webinf
- · metainf
Files specified in these tags will go into their particular directories.
Listing A offers an example of the war task, which will build a file named ApplicationVersion2.war. It gets its Web.xml file from xml/av2-web.xml and includes every file in the HTML directory. Additionally, it puts all the files in our lib/ext directory (except the Oracle ones) into the WAR’s WEB-INF/lib directory and puts all servlets sitting in the build/servlets directory into the WEB-INF/classes directory.
Not ready to move to .NET?
Migrating from Java to .NET isn’t an easy task, and you may just be better off with your existing application. “Five reasons against migrating Java EJB applications to .NET” spells out why you should stick with Java. Don’t miss this article’s recent discussion posts.
Bind an object to the HttpSession
Sometimes, you want to create an object, maybe as a resource or cache, that will last for the lifetime of a user’s servlet or JSP session. This can be a problem if you also want that object to be available from another location. You don’t want the object to get garbage collected when the session is terminated. You can prevent this problem by implementing the HttpSessionBindingListener.
Listing B gives you a simple example. (Note that try/catches are ignored.)
Binding this object to the session really requires no work. All you have to do is place the object in the session. If an object placed in the session implements HttpSessionBindingListener, the session automatically makes it a listener and will notify it when bound and unbound.
By implementing HttpSessionBindingListener, you can fully place objects into the session’s scope, knowing that even their creation and destruction in that scope can be monitored.
