Chapter 9. Reloading Classes at Runtime

Table of Contents

9.1. Overview
9.2. Basic Configurations and Operation
9.2.1. Configuring Servers
9.2.2. Configuring Applications
9.2.3. Configuration Results
9.2.4. Applications and Modifications Supported by JEUS HotSwap
9.2.5. JEUS HotSwap Constraints

This chapter describes servlet auto reloading that helps reduce the web application development time.

9.1. Overview

In general, the Java EE development life cycle consists of the following steps.

  1. Edit

  2. Build

  3. Deploy

  4. Test

Servlet classes are often modified when developing Java EE applications, especially web applications. Much effort has been made to shorten the development process, and WebLogic 10.3 provides functions that reduce the redeployment process through FastSwap.

Java EE 5 introduced a function that can redefine classes without terminating the class loader or instances while applications are running, but declared fields and methods cannot be modified.

Up to JEUS 6, to reload a modified class, the application must be redeployed or a new class loader must be created using automatic reloading to replace the existing class loader. Automatic reloading can be executed at a fixed interval or on demand.

However, if the application is too big, it takes a long time to redeploy the application and automatic reloading uses as much overhead as redeployment because it recreates the class loader.

JEUS 7 provides a function that can reload modified Java classes dynamically without reloading them (Automatic reloading) by using the JDK instrumentation package. This function is called JEUS HotSwap. It can currently only be used for web application classes.

Note

The automatic reloading (JEUS HotSwap activated/inactivated)function can generate unexpected system overhead in a production environment, so it is recommended to only use it in a development environment.

9.2. Basic Configurations and Operation

This section describes how to configure and operate automatic reloading.

9.2.1. Configuring Servers

JEUS must be configured to use HotSwap before it is started. Auto reloading that does not have the JEUS HotSwap function starts without the system option when the server is started.

The system option is jeus.server.useHotSwapAgent and its default value is 'false'. If it is not set, auto reloading cannot be used.

The following are examples of configuring JEUS start scripts.

  • startDomainAdminServer script configuration

    [Example 9.1] Configuring Automatic Reloading: <<startDomainAdminServer>>

    ...
        "${JAVA_HOME}/bin/java" $VM_OPTION  $SESSION_MEM
        -Xbootclasspath/p:"${JEUS_HOME}/lib/system/extension.jar"
        ...
        -Djeus.server.useHotSwapAgent=true
        ...
        jeus.launcher.Launcher ${BOOT_PARAMETER}
    ...

  • startManagedServer script configuration

    [Example 9.2] Configuring Automatic Reloading: <<startManagedServer>>

    ...
        "${JAVA_HOME}/bin/java" $VM_OPTION  $SESSION_MEM
        -Xbootclasspath/p:"${JEUS_HOME}/lib/system/extension.jar"
        ...
        -Djeus.server.useHotSwapAgent=true
        ...
        jeus.launcher.ManagedServerLauncher ${BOOT_PARAMETER}
    ...

Enable automatic reloading during development, but disable it in the production environments.

9.2.2. Configuring Applications

To use automatic reloading, <auto-reload> must be configured in jeus-web-dd.xml. To use JEUS HotSwap, <use-jvm-hotswap> inside <auto-reload> must be set to true.

These functions can only be used in class files that are packaged as directories (exploded directories) of web applications. These functions are used to dynamically reload modified classes in already deployed directories. In other words, they can only be used for modified classes in the 'WEB-INF/classes' directory.

Configure <auto-reload> in jeus-web-dd.xml as in the following. Set the monitoring interval for auto reloading in WebAdmin. For more information about setting the monitoring interval in WebAdmin, refer to "1.6.2. Monitoring".

[Example 9.3] Configuring Automatic Reloading: <<jeus-web-dd.xml>>

<jeus-web-dd  xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0"> 
     . . .
     <auto-reload>
        <enable-reload>true</enable-reload>
        <use-jvm-hotswap>true</use-jvm-hotswap>
        <check-ok-demand>true</check-ok-demand>
     </auto-reload>
     . . .
</jeus-web-dd>

For more information about each tag, refer to "9.2.3. Configuration Results".

9.2.3. Configuration Results

In JEUS, automatic reloading is performed when a class is modified after the application has been deployed.

Automatic reloading uses the following settings.

TagDescription
<enable-reload>Option to use automatic reloading. Must be set to true.
<use-jvm-hotswap>
  • true: Instead of replacing the class loader, redefines the modified classes or applies the changes using class retransformation. If there are any classes that cannot be redefined or retransformed during the process, JEUS HotSwap will stop and auto reloading is executed to reload the changes. For information about class modifications that cannot be applied using JEUS HotSwap, refer to "9.2.5. JEUS HotSwap Constraints".

  • false: JEUS HotSwap is not used. Replaces the class loader of the application to reload the modified classes.

<check-on-demand>
  • true: When a request is received, this immediately finds the modified files by checking the last modified time of each class based on the application class loader.

    If modified classes are found, automatic reloading will be performed according to the <use-jvm-hotswap> setting.

  • false: The web engine finds modified files by checking the last modified time of each class based on the application class loader at the interval set in 'Check Class Reload'. The default value is 300 seconds. For more information about 'Check Class Reload', refer to "1.6.2. Monitoring".

    If modified classes are found, automatic reloading will be performed according to the <use-jvm-hotswap> setting.

9.2.4. Applications and Modifications Supported by JEUS HotSwap

JEUS HotSwap supports POJOs and web application classes in exploded directories.

The following modifications are supported by JEUS HotSwap.

  • Adding and deleting static class constructors

  • Adding and deleting regular class constructors

  • Changing static method bodies

  • Changing regular method bodies

The following list of class modifications are supported by JEUS HotSwap.

  • Java class instances (non-abstract)

    Java Change TypeSupportedNotes
    Adding and deleting methodsNo 
    (1) Adding and deleting fieldsNo 
    (2) Changing method bodiesYes 
    (3) Adding and deleting constructorsYes 
    (4) Changing field modifiersNo 
  • Static classes

    Java Change TypeSupportedNotes
    Adding and deleting methodsNo 
    Changing method bodiesYes 
  • Abstract Java classes

    Java Change TypeSupportedNotes
    Adding and deleting abstract methodsNo 
    Change types (1)-(4) of Java class instancesYes 
  • Final Java classes

    Java Change TypeSupportedNotes
    Change types (1)-(4) of Java class instancesYes 
  • Final Java methods

    Java Change TypeSupportedNotes
    Change types (1)-(4) of Java class instancesYes 
  • Final Java fields

    Java Change TypeSupportedNotes
    Change types (1)-(4) of Java class instancesYes 
  • Enumerations

    Java Change TypeSupportedNotes
    Adding and deleting variablesNo 
    Adding and deleting methodsNo 
  • Anonymous internal classes

    Java Change TypeSupportedNotes
    Adding and deleting fieldsInvalidJava does not support this.
    Adding and deleting methodsNo 
  • Static internal classes

    Java Change TypeSupportedNotes
    Change types (1)-(4) of Java class instancesYes 
  • Regular internal classes

    Java Change TypeSupportedNotes
    Change types (1)-(4) of Java class instancesYes 
  • Java interfaces

    Java Change TypeSupportedNotes
    Adding methodsNo 
  • Java Reflection

    Java Change TypeSupportedNotes
    Accessing existing fields and methodsYes 
    Accessing new methodsNoNew methods are not visible when using reflection.
    Accessing new fieldsNoNew fields are not visible when using reflection.
  • Class Annotations

    Java Change TypeSupportedNotes
    Adding and deleting class annotationsNo 
  • Annotations

    Java Change TypeSupportedNotes
    Adding and deleting method and property annotationsNo 
  • Exception classes

    Java Change TypeSupportedNotes
    Change types (1)-(4) of Java class instancesYes 
  • EJB interfaces

    Java Change TypeSupportedNotes
    Adding and deleting methodsNoChanging EJB interfaces related to reflection is not supported.
  • EJB 3.0 Session and MDB implementation classes

    Java Change TypeSupportedNotes
    Adding and deleting methods and fieldsNoOnly supported classes among the classes referenced by EJB can be modified.
  • EJB 2.X Entity Beans

    Java Change TypeSupportedNotes
    Adding and deleting methods and fieldsNoOnly supported classes among the classes referenced by EJB can be modified.
  • EJB Interceptors

    Java Change TypeSupportedNotes
    Adding and deleting methods and fieldsNoOnly supported classes among the classes referenced by EJB can be modified.

9.2.5. JEUS HotSwap Constraints

Not all types of changes are supported by JEUS HotSwap. If an attempt is made to make an unsupported change, the JDK will return an UnsupportedOperationException. JEUS receives the error message and logs it as "Re-transforming all modified classes in the servlet context [AAA] failed." When this happens,the application will be not updated dynamically, but instead, an automatic reloading will be executed.

Retransforming all modified classes in the servlet context [AAA] failed.

The following changes are not supported in JEUS HotSwap.

  • Since Java reflection results cannot include newly modified fields and methods, using reflection on modified classes can cause unexpected results.

  • Changing the existing class hierarchy is not supported.

    For example, changing a list that implements class interfaces or modifying the class' superclass are not supported.

  • Adding or deleting Java annotations are is supported, due to the limitations of reflection.

  • Adding or deleting EJB interface methods is not supported because it requires the reflection of the changes.

  • Adding or deleting enumeration constants is not supported.

  • Adding or deleting finalize methods is not supported.