Sun ONE logo      Previous      Contents      Index      Next     

Sun ONE Application Server 7 Getting Started Guide

Chapter 8
Modifying the Sample Application

Sun ONE Application Server 7 provides several dynamic deployment capabilities that can greatly improve developer productivity. This chapter introduces these features and leads you through several practical examples based on 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 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 your application during redeployment. These features apply to both EAR level deployment as well as to deployments and individual web and EJB JAR module deployments. No server configuration changes are required to enable dynamic deployment and redeployment.

Note

Dynamic Redeployment in Operational Environments Although dynamic redeployment is positioned primarily as a development time feature, you can make use of this feature in operational environments as long as you take the following steps prior to redeploying an application:

1. Redirect new requests for the application to another application server instance.

2. Allow existing sessions to terminate.

You will have to use external load balancers or other means to redirect incoming requests and can use built in monitoring facilities of the application server to determine when all sessions associated with the application have terminated.

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 application 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:

This section contains the following topics:

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:

    2. 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 “MODIFIED” to the front of the string.

    3. For example: System.out.println("\nMODIFIED GreeterDBServlet is executing...");.

  3. Save your changes.
  4. Recompile and reassemble the sample:
    1. Navigate back up to the sample's src directory.
    2. Execute asant without any options to recompile and reassemble the application.

      3. 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.
    1. Ensure that the administrative server is running. If it is not running, you can quickly start it by executing:

      2. asadmin start-instance admin-server

    2. Access the administrative console.
    3. Under the server1 node, expand the Applications node, select the Enterprise Apps node folder and click Deploy.
    4. Deploy the application in the same manner as you did in the Deploying the Application section of "Becoming Familiar with the Sample Applications".

      5. 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.

    7. Note the presence of the word “MODIFIED” at the start of the following stdout message:

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

    Tip

    Application reload messages: Further evidence of the application being fully reloaded can be viewed in the server event log file. During redeployment of the sample, the following messages are displayed to the event log of the targeted server instance:

    INFO: CORE5022: All ejbs of [jdbc-simple] were unloaded successfully!

    INFO: LOADER5010: All ejbs of [jdbc-simple] loaded successfully!

    INFO: CORE3276: Installing a new configuration

    INFO: WEB0100: Loading web module [jdbc-simple:jdbc-simple.war] in virtual server [server1]

    INFO: WEB0100: Loading web module [default-web-module] in virtual server [server1]

    INFO: CORE3280: A new configuration was successfully installed

    INFO: WEB4004: Closing web application environment for virtual server [server1]

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

To dynamically reload static content, perform the following steps:

  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:

    3. 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:

    4. <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.

    6. 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

To dynamically reload JavaServer Page (JSP) files, perform the following steps:

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

    2. 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:

    3. 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:

    4. <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.

    6. 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.

    7. Tip

    Dynamic reloading of web content: Note that in the static content and JSP examples of dynamic reloading, you did not have to enable the dynamic reloading switch in the application server instance. By default, the web container dynamically reloads web content. Within the sun-web.xml file of a web application, you can set a switch that will tell the web container to never reload JSP files. This useful when you want to avoid inadvertent activation of modified and deployed JSP sources files.

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:

    2. install_dir/samples/jdbc/simple/src/samples/jdbc/simple/ejb/

  2. Edit the GreeterDBBean.java file:

    3. Find the line System.out.println("GreeterDB EJB is determining message..."); and modify it by adding “MODIFIED” 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:
    1. Navigate back up to the sample's src directory.
    2. 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.
    1. Ensure that the administrative server is running. If it is not running, you can quickly start it by executing:

      2. asadmin start-instance admin-server

    2. Access the administrative console.
    3. Select the Enterprise Apps node folder and click Deploy.
    4. Deploy the application in the same manner as you did in the previous section.

      5. Again, note the speed at which redeployment occurs when no changes have been made to the EJB interfaces.

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

    7. 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.
  5. Click Save.
  6. Select the Server instance server1, click Apply Changes, and restart the server instance.

    7. Figure 8-1  Reload enabled
    This figure shows the Applications Properties page with Reload Enabled highlighted.

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

Modify EJB Implementation Class

To modify the EJB implementation class, perform the following steps:

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

    2. 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..."); and modify it by adding “MODIFIED AGAIN” to the front of the string.

    3. For example: System.out.println("MODIFIED AGAIN GreeterDB EJB is determining message...");.

  3. Save your changes.

Recompile and Copy to Deployment Area

To recompile the application and copy it to the deployment area, perform the following steps:

  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.

    3. asant compile

    You should see that one source file was modified and 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.

    4. You will find the newly generated EJB implementation 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:

    5. 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:

Rerun the Application

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

    2. 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.

    3. Tip

    Manual copying is fast? In typical command line oriented development scenarios, you’ll use either an Ant build.xml or a Makefile target named something like update to automate the process of copying modified .class files from your development workspace area directly to the application’s deployment area and “touching” the .reload file.

    When using an IDE, you will typically configure the compiler options in the IDE such that .class files are created in the deployment area of the application server. Consequently, whenever you recompile a specific Java source file, the resulting .class file will automatically be copied to the deployment area. Then all you'll need to do is modify the .reload file in another source editing window and the application will be automatically reloaded.

    These approaches yield super fast development edit-compile-test cycles because the process of reassembling and performing a formal redeployment is removed from the overall process. Note that dynamic reloading does not involve the administrative server. In fact, using this method of updating your deployed application, you need not keep your administrative server up and running.

Proceed to Chapter 9, "Exploring the Server Further" to learn about commonly performed tasks.



Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.