        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
Facilities Guide
CHAPTER 1
This chapter describes how to use the Novell exteNd Application Server's JSP File System (JSP/FS) deployment to speed your JSP development. With JSP/FS you can deploy your Web application to the file system and instantly see the result of changes you make—without redeployment. The chapter contains these sections:
This section provides a quick introduction to JSP pages and their deployment.
The JavaServer Pages technology is an important part of Sun's J2EE platform, which recommends using JSP pages (with supporting servlets) to provide the core of the user interface of your application. JSP pages are typically used in Web-based J2EE applications (Web applications). A Web application includes JSP pages, servlets, JavaBeans, utility classes, images, and so on that are packaged in an archive called a Web application archive (WAR) file. These applications are accessed by browser clients.
The application server provides full support for JSP pages.
For more information on JSP pages and how to create them, see the exteNd DirectorTM help.
To make your Web application available to users, you deploy it to an application server. Users access your application by specifying appropriate URLs in their browsers.
But when developing, testing, and refining your application, you want fast turnaround—you want to make a change to your JSP pages and immediately see the result in a browser without having to redeploy the application. With JSP/FS, you can.
After deploying your application to the file system, you can create or change a JSP page, refresh the browser, and immediately see the change. There is no need to redeploy.
Similarly, you can change any static resource in your application and see the change immediately. (A static resource is any file that the server serves as is. Static resources include HTML files, images files, and style sheets.)
JSP/FS is:
Meant only to enhance development. Don't use it with your production applications, instead see Putting your application into production.
If you are using Novell exteNd Director to do your development and deployment, you don't have to perform the procedures described in the rest of this chapter. You need only to specify Enable Rapid Deployment in your project's deployment settings when you deploy your WAR (or EAR containing a WAR). exteNd Director's deployment tools will manage everything for you, including:
Updating the deployment plan with the proper specification for JSP/FS
Managing changes you make in your project's files (including creating and removing a RELOAD file as necessary, as described in Making changes to Java source files)
You continue to work with your project's files as usual. Changes will be reflected immediately in your deployed application.
When you are ready to do your production deployment, simply deselect Enable Rapid Deployment in your project's deployment settings and redeploy.
For more information, see exteNd Director help.
To use file system deployment, you do not need to do anything special when you begin your Web application development. You'll set up your development area using a directory structure that conforms to the format required for Web applications. Then when you are ready to test your application, you package it in a WAR file.
What must be in the WAR file To create your WAR file for file-system deployment, all you need is:
A deployment descriptor for the application. The file must be named web.xml and must be in the WEB-INF directory.
There are different versions of the Sun J2EE Web application DTD. Each version of the Java Servlet Specification provides complete documentation on each tag. You can find these documents on the Sun Java Web site at java.sun.com/j2ee/docs.html.
Creating the WAR file You can create the WAR file using the archive tool of your choice. For example, you can use Novell exteNd Director or Sun's jar utility.
Once you have the WAR file, you are ready to deploy it to the file system. To deploy a J2EE archive (such as a WAR file), you create a deployment plan, an XML file that specifies application server–specific information about how to manage the Web application and how it should be deployed.
The WAR's deployment plan must be in the correct format. The deployment plan DTDs are located in the server's Resources/DTDCatalog directory. Different server versions use different DTDs. See J2EE Archive Deployment for information on which DTD is appropriate for your server version.
The deployment plan for file-system deployment is the same as for a production deployment, with one exception: it includes a line within the <warJar> section that specifies that you want the server to deploy the application to the file system. To deploy to the file system, include this line in your deployment plan:
<deployToFilesystem type="Boolean">true</deployToFilesystem>
Example The following shows how to use the <deployToFilesystem> element:
<warJarName>C:\MyProjects\JSPSample\JSPSample.war</warJarName>
<isEnabled type="Boolean">True</isEnabled>
<deployToFilesystem type="Boolean">true</deployToFilesystem>
<sessionTimeout type="String">5</sessionTimeout>
<urls type="StringArray">
<el>JSPSample</el>
</urls>
<deployedObject type="String">JSPSample</deployedObject>
</warJar>
</warJarOptions>
Now run the DeployWAR SilverCmd to deploy your application (you can also use DeployEAR, as long as it includes your WAR file).
What happens The application is deployed to the file system as follows: the server expands the WAR file in the directory /webapps/DBname/URL in the server's installation directory, where:
DBname is the name of the database containing the application deployed to the file system
URL is the URL specified in the deployment plan for the application (if you have specified more than one, the first one is used)
Example Here is the structure of the sample application whose deployment plan is shown above (entries in bold are directories):
JSPSample jsps (directory containing the JSP pages) WEB-INF web.xml (deployment descriptor) classes (directory containing the supporting class files) tlds (directory containing the TLD files)
Here is the deployment command line:
SilverCmd DeployWAR localhost JSPSampleDB JSPSample.war -f JSPSampleDeplPlan.xml -o
After deploying this application to the file system, the WAR file is expanded in /webapps in the server's installation directory as follows:
ServerInstallDir webapps JSPSampleDB (directory whose name is the deployment database) JSPSample (directory whose name is the URL in the deployment plan) com (directory where JSPs will be compiled -- see below) jsps WEB-INF web.xml classes tlds
The subdirectories under webapps/JSPSampleDB/JSPSample make up the deployment area, and you can work with the application there.
Once you have deployed your application to the file system, you can make changes in the deployment area and immediately see the result of the changes.
To see the result To see the result of your change, simply save the file(s) in the deployment area, go to your browser, and specify the appropriate URL.
For example, to see the result of changing sample.jsp, you would specify an URL similar to this:
http://localhost/JSPSampleDB/JSPSample/jsps/sample.jsp
What the server does The application server checks to see whether the JSP page has ever been accessed. If not, it compiles it and displays the result in the browser. The server stores the resulting Java and class files in the com/sssw/gen/jsp directory in the deployment area.
Similarly, the server checks to see whether the JSP page (the JSP source file) has been updated since it was last accessed. If so, the file is recompiled and redisplayed.
Also, the server serves updated static resources as needed.
If there is an error If there are any JSP compilation errors for the requested page, the server generates an HTML page describing the error and returns it with a 500 status code to the client.
If there is an error compiling a JSP page other than the one requested, the server cannot intercept the failure. Depending on where in the compilation process the error occurred, you might see an error message in the generated JSP page with a link that describes the error. You can prevent the server from trying to compile JSP pages that are known to fail by using the <excludedJSPs> tag in the deployment plan.
Making changes to Java source files Sometimes in the course of development you will need to update utility classes, servlets, JAR files, and so on in the application and will want to refresh your deployment area.
To refresh the deployment area:
Compile the classes and refresh any JARs that need updating.
Copy the updated CLASS and JAR files to the appropriate locations in the deployment area.
Create a file named RELOAD (all uppercase) in the root of the deployment area.
In the sample deployment, you would create RELOAD in webapps/JSPSampleDB/JSPSample.
TIP: To easily create the file, open a DOS command prompt, change to the directory, type copy con RELOAD, then press Return, Ctrl+Z, Return.
Access your application in the browser.
The server will automatically reload the application, getting all the updated files, and delete the RELOAD file.
You can now continue to make changes to JSP pages in the updated deployment area.
Redeploying the application to the file system After deploying to the file system, you shouldn't redeploy your application to the file system with DeployWAR. Instead, work with your application as described above. When you are ready to put your application into production, follow the procedure in Putting your application into production next.
If (in error) you do redeploy your application to the file system with DeployWAR, the server notices that the deployment directory already exists in webapps. It renames that directory to DeploymentDir.1, then redeploys the application to the file system. That means the current application continues to be DeploymentDir, with the previous version archived as DeploymentDir.1. If you do the deployment again, DeploymentDir is renamed DeploymentDir.2, and so on. The current application is always DeploymentDir, and the version before that is archived as the highest numbered DeploymentDir.n. The server is responsive only to changes in DeploymentDir.
In the sample shown, if the application is deployed to the file system a second time, webapps/JSPSampleDB/JSPSample is renamed to JSPSample.1, and the current application is deployed to JSPSample.
JSP/FS is meant only for use in the development phase of your application. When you have completed the application and are ready to put it into production, do the following.
To put your application into production:
Bring your development area up to date with the changes you made in the deployment area.
Delete or comment out the <deployToFilesystem> line in the deployment plan.
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...