Document Affected: Sun ONE Application Server 7 Developer's Guide

This documentation pertains to the use of indexed deployment directories.

The numbering scheme part of a deployed application's directory name has been implemented as an indexing mechanism. This mechanism enables a developer to modify a JAR or class file associated with the deployed application. This mechanism is significant to the Windows platform because of a sharing violation error that occurs during an attempt to overwrite a loaded file, Windows places a file lock on the loaded file. The file is loaded into the server instance or the IDE during session startup. With the sharing violation error, two options are possible:

• Compile the updated class file (originally part of that JAR file) and place it first in the classpath in order to be loaded before the older classes. Then allow for the Sun ONE Application Server to reload this application (as long as reload is active).

• Update the JAR file, create a new EAR file, and redeploy the application.

Redeployment of the application on the Solaris platform is not necessary because no file-locking constraints exist.

When changing an already deployed application on the Windows platform for IDE setup, ANT file copy, or compile or other operations, be aware of another change. A new directory is created with an incremented index number as the workaround for the file-locking constraint. For example, on the Solaris platform the J2EE application, helloworld, is deployed to the Sun ONE Application Server with the following directory structure:

appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1

A change is then to be made to a servlet that is part of this deployed application (for example, HelloServlet.java). The Sun ONE Studio IDE is started, the source file for this servlet is changed and compiled with the javac target set to the previously mentioned directory. With the source compiled in the proper location, a reload file exists for this application. The reload flag in server.xml is set to true, and with the server instance running, the changes become effective without reassembly of the application and redeployment.

For the Windows platform, the JAR or class file cannot be altered and updated because of the file-locking issue. Therefore, you can resolve this issue on Windows in one of two ways:

• Compile the changed source file and prepend the class file or JAR in the classpath in order to make the source changes effective.

• Make the changes to the helloworld source, assemble it, and redeploy it without undeploying the previous deployment of helloworld.

The second option is the preferred method because this option results in the use of the incremented index number appended to the deployed application's directory name. After a second deployment of helloworld, the directory structures would resemble the following:

appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1

appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_2

The second deployment of helloworld would be deployed under helloworld_2.