Sun ONE Application Server 7 provides several dynamic deployment capabilities that can greatly improve developer productivity. This section introduces these features and leads you through several practical examples using the sample application that you exercised in the previous section.

Dynamic Deployment and Reloading Features

Sun ONE Application Server 7 supports the following features to support fast development cycle times:

Dynamic Deployment and Redeployment

Dynamic Deployment and Redeployment of J2EE[tm] applications enables you to perform initial deployments of applications and subsequent redeployment without needing to restart the targeted application server instance. The application server completely reloads each application during redeployment. These features apply to both EAR level deployment as well as to deployments of individual web and EJB[tm] JAR modules. No server configuration changes are required to enable dynamic deployment and redeployment.

Smart Redeployment

Smart Redeployment ensures that redeployment of EJB-based applications occurs as fast as possible. During redeployment of an application, the stubs and skeleton classes are regenerated only for those EJBs whose interfaces have changed since the last deployment. Since stub and skeleton generation incurs the most overhead of any operation during deployment, smart redeployment is a significant time saver. No server configuration changes are required to activate this feature. Smart redeployment is used during every redeployment operation.

Dynamic Reloading

Dynamic Reloading refers to the application server's ability to reload discrete class files, web content changes and deployment descriptor changes without requiring a complete reassembly and redeployment of the application and without restarting the application server. To support dynamic reloading of class files and deployment descriptor changes, the server instance monitors a special file named ".reload" residing at the top level of the deployment area of the application or individually deployed module. When a developer or make facility modifies or "touches" the .reload file, the server instance will completely reload the application or individually deployed module. This feature requires that you enable it explicitly for each application server instance. Since the monitoring incurs additional overhead, this feature is oriented towards development environments only.

Even without the dynamic reloading flag enabled, the web container of the application server automatically monitors web content such as static content and JavaServer Pages (JSP) files for modification. The web container will automatically reload a modified file when it is next accessed.

You may encounter the term "hot deploy" while reading about applications servers. In many cases, hot deploy refers to dynamic deployment, dynamic redeployment and dynamic reloading. However, make sure you look closely at the details of the application server documentation to determine if all of these capabilities are supported by a specific product.

Modifying Application Components

In this section, you will modify the following types of content contained in the "jdbc-simple" sample application:

Web Content Redeployment and Reloading

EJB Redeployment and Reloading

Dynamically Redeploying Servlet Class Files

This exercise demonstrates the dynamic redeployment feature of the application server by leading you through the steps to modify a servlet class file, reassemble the application and dynamically redeploy the application without restarting the application server.

1. Navigate to the source code directory of the servlets in the example:

<install_dir>/samples/jdbc/simple/src/samples/jdbc/simple/servlet/

2. Edit the GreeterDBServlet.java file: Find the line:

System.out.println("\nGreeterDBServlet is executing...");

and modify it by adding "My" to the front of the string.

For example:

System.out.println("\nMODIFIED GreeterDBServlet is executing...");

3. Save your changes.

4. Recompile and reassemble the sample.

4a. Navigate back up to the sample's src/ directory.

4b. Execute asant without any options to recompile and reassemble the application.

You should notice that a single source file was recompiled while the rest of the Java source files were not recompiled.

5. Redeploy the sample application using the administrative console.

5a. Ensure that the administrative server is running. If it is not running, you can quickly start it by executing:

asadmin start-instance admin-server

5b. Access the administrative console.

5c. Under the server1 node, expand the Applications node, select the Enterprise Apps node folder and click Deploy...

5d. Deploy the application in the same manner as you did in the Deploying the Application section of Deploying and Running the Sample Application.

Note the speed at which redeployment occurs when no changes have been made to the EJB interfaces. This speed is a result of the smart redeployment feature of the application server.

6. Rerun the application while monitoring the server event log file.

Note the presence of the word "MODIFIED" at the start of the following stdout message:

INFO: CORE3282: stdout: MODIFIED GreeterDBServlet is executing..."

This exercise demonstrated the capability to dynamically redeploy a modified application in which a servlet class file was changed without requiring a restart of the application server instance.

Dynamically Reloading Static Content

1. Access the "jdbc-simple" application and note the title string appearing at the top of the application's main page.

2. Navigate the to application deployment area of the application server instance. Specifically to the web module's area:

<domain_config_dir>/domain1/server1/applications/j2ee-apps/jdbc-simple_n/jdbc-simple_war/

3. Open the index.html file and modify the following section by adding "MODIFIED " at the beginning of the <TITLE> tag:

<head>
<title>MODIFIED JDBC-SIMPLE Sample Application</title>
</head>

4. Save your changes.

5. Now access the main page of the application again, enter your name and click the Process button.

If you do not see the modified title of the web page at the top of the browser window, press SHIFT and click on the browser's Reload button to reload the content from the application server.

Dynamically Reloading JSP Files

1. Access the "jdbc-simple" application, enter your name, and click the Process button.

Note the content of the resulting page. You will be modifying the JSP that displays this page.

2. Navigate the to application deployment area of the application server instance. Specifically to the web module's area:

<domain_config_dir>/domain1/server1/applications/j2ee-apps/jdbc-simple_n/jdbc-simple_war/

3. Open the GreeterDBView.jsp file and modify the following section by adding "MODIFIED " at the beginning of the <TITLE> tag:

<head>
<title>MODIFIED JDBC-SIMPLE Sample Application</title>
</head>

4. Save your changes.

5. Now access the application again and note the presence of the new title at the top of your browser window.

Since the web container must recompile the JSP file after sensing its modification, there will be a noticeable lag when running the application the first time after the modification has been made.

6. Run the application again. You will notice the speed is greatly improved because the JSP has already been compiled.

Dynamically Redeploying EJB Implementation Class Files

In the same manner that you modified the servlet class file, in this exercise you will modify the EJB implementation class file and leverage dynamic redeployment to quickly retest the application without restarting the application server.

1. Navigate to the source code directory of the EJB in the example:

<install_dir>/samples/jdbc/simple/src/samples/jdbc/simple/ejb/

2. Edit the GreeterDBBean.java file. Find the line:

System.out.println("GreeterDB EJB is determining message...");

Modify it by adding "My" to the front of the string. For example:

System.out.println("MODIFIED GreeterDB EJB is determining message...");

3. Save your changes.

4. Recompile and reassemble the sample.

4a. Navigate back up to the sample's src/ directory.

4b. Execute asant without any options to recompile and reassemble the application.

You should notice that a single source file was recompiled while the rest of the Java source files were not recompiled.

5. Redeploy the sample application using the administrative console.

5a. Ensure that the administrative server is running. If it is not running, you can quickly start it by executing:

asadmin start-instance admin-server

5b. Access the administrative console.

5c. Select the Enterprise Apps node folder and click Deploy...

5d. Deploy the application in the same manner as you did in the previous section.

Note the speed at which redeployment occurs when no changes have been made to the EJB interfaces. This speed is a result of the smart redeployment feature of the application server.

6. Rerun the application while monitoring the server event log file.

Note the presence of the word "MODIFIED" at the start of the following stdout message:

INFO: CORE3282: stdout: MODIFIED GreeterDB EJB is determining message...

This exercise demonstrated the capability to dynamically redeploy a modified application in which an EJB implementation class file was changed without requiring a restart of the application server instance.

Dynamically Reloading EJB Implementation Class Files

This exercise demonstrates the dynamic reloading feature. Although the steps required to take advantage of dynamic class reloading appears more complex than that used with dynamic redeployment, the speed enhancements of dynamic reloading surpass that of dynamic redeployment. Using either a make facility or your Java compiler's class file destination setting to automate the process of copying discrete files from your build area to the deployment area will help you take advantage of the benefits of the dynamic reloading feature.

In the first part of this exercise you will make another modification to the GreeterDBBean's implementation class. After recompiling the EJB, you will manually copy it to the application's deployment area. Then you'll create the special .reload file and rerun the sample application. The creation of this special .reload file is your means to inform the server instance that one or more new files have been copied to the application deployment area and that the instance should reload the entire application. During a reload of the complete application, the application server instance flushes all of application components from memory and reloads them again. All user sessions associated with the application are also flushed during an application level reload operation.

After copying the modified class file and creating the .reload file, you can almost immediately test the modified application.

There is no need to reassemble and formally redeploy your applications when leveraging the dynamic reloading facility.

Enable Dynamic Reloading

Before exercising dynamic class reloading, you will need to first enable dynamic reloading.

Since the dynamic reloading feature incurs additional overhead by constantly monitoring the presence and modification of .reload files, this setting should not be enabled in operational environment.

1. Access the administrative console.

2. Select the "server1" instance node.

3. Select the Applications folder.

4. Select the Reload Enabled checkbox.

4. Click Save.

5. Select the Server instance "server1", click Apply Changes and then restart the server instance.

Now modify the EJB implementation class, recompile it and manually copy it to the deployment area.

Modify EJB Implementation Class

1. Navigate to the source code directory of the EJB in the example:

<install_dir>/samples/jdbc/simple/src/samples/jdbc/simple/ejb/

2. Edit the GreeterDBBean.java file again. Find the line:

System.out.println("MODIFIED GreeterDB EJB is determining message...");

Modify it by adding "My, this is fun!" to the front of the string. For example:

System.out.println("MODIFIED AGAIN GreeterDB EJB is determining message...");

3. Save your changes.

Recompile and Copy to Deployment Area

1. Navigate back up to the sample's src/ directory.

2. Execute asant with the compile target name to recompile the modified Java source file. The compile target is used to avoid a complete reassembly of the application.

asant compile

You should see that a single source file was recompiled while the rest of the Java source files were not recompiled.

3. Manually copy the newly generated class from the local build/classes/ directory to the application deployment area within the target application server instance:

You will find the newly generated servlet class at the following location:

<install_dir>/samples/jdbc/simple/build/classes/samples/jdbc/simple/
ejb/GreeterDBBean.class

4. Copy this file to the following location:

<domain_config_dir>/domain1/server1/applications/j2ee-apps/
jdbc-simple_n/jdbc-simpleEjb_jar/samples/jdbc/simple/ejb/

Create .reload File

Create an empty file named .reload at the root of the application's deployment directory.

On Windows, use Notepad to create a new text file and save it to the following location:

<domain_config_dir>/domain1/server1/applications/j2ee-apps/jdbc-simple_n/.reload

On Unix, simply execute "touch .reload" in the directory deployment directory specified above to create an empty file.

Rerun the Application

1. Rerun the application while monitoring the server event log file.

Note the presence of the words "MODIFIED AGAIN " at the start of the following stdout message:

INFO: CORE3282: stdout: MODIFIED AGAIN GreeterDB EJB is determining messa..."

2. Modify the EJB implementation class again by changing the println()statement. Recompile, copy the EJB implementation class and modify the .reload file again to effect a dynamic reload of the application.

Proceed to Exploring the Server Further to learn about commonly performed tasks.