Appendix B       Runtime Considerations


This appendix convers the following topics:

• Runtime Environments

• The Classloader Hierarchy

• Dynamic Reloading

Runtime Environments

---

Whether you register a component as a module or as an application, registering affects both the file system and the registry. Figure B-1 shows the module runtime environment. Figure B-2 shows the application runtime environment.

Module Runtime Environment

The figure below illustrates the environment for module-based deployment. Note that for file system entries, modules are extracted as follows:

install_dir/ias/APPS/modules/module_name/extracted_class

Registry entries are added under this key:

SOFTWARE\iPlanet\Application Server\6.0\J2EE-Module\module_name

---

Tip	All modules are extracted under the same directory, and all modules are extracted to the same LDAP location, therefore it is important that no two modules have the same name.

---

Figure B-1    Module runtime environment

Application Runtime Environment

The figure below illustrates the environment for application-based deployment. Note that for file system entries, applications are extracted as follows:

install_dir/ias/APPS/app_name/module_name/extracted_class

For Registry entries, modules within the application are added under this key:

SOFTWARE\iPlanet\Application Server\6.0\J2EE-Module\module_name

Figure B-2    Application runtime environment

The Classloader Hierarchy

---

In a Java Virtual Machine (JVM), the class loaders dynamically load a specific java class file needed for resolving a dependency. For example, when an instance of java.util.Enumeration needs to be created, one of the classloaders loads the relevant class into the environment. Class loaders in the iPlanet Application Server runtime follow a rigid hierarchy that is illustrated in Figure B-3.

Figure B-3    Classloader runtime hierarchy

For Java 1.2, a delegation design is used to load classes. In the delegation design, a custom class loader delegates class loading to its parent. A class loader parent can be either the Bootstrap Classloader or another custom class loader. If the parent classloader can't load a class, a new method, called findClass(), is called on the classloader subclass. In effect, the custom classloader is responsible for loading only the classes not available to the parent. These would presumably be classes that come from a new type of class repository. Each class loader looks at a different repository for classes. The classloaders and the files they examine are described in Table B-1.

Table B-1    iPlanet Application Server classloaders

Classloader	Description
Bootstrap	The Bootstrap Classloader looks for runtime classes in rt.jar and internationalization classes in i18n.jar.
Extension	The Installed Extensions Classloader looks for classes in JAR files in the lib/ext directory of the JRE.
System	The System Classpath Classloader looks for classes in JAR files on paths specified by the system property java.class.path. To have a class loaded by the System Classloader, you must include the relevant directory in the class path. This means either in KJS (on Unix), the environment (on Unix or NT), or in the \Software\iPlanet\Application Server\6.0\Java\Classpath registry entry (on NT.)
Module	The iPlanet Application Server Module Classloader looks for classes in all directories under install_dir/ias/APPS/modules/*. All modules share this classloader.
Application	Each registered J2EE application is loaded by its own class loader, which looks for classes under install_dir/ias/APPS/app_name and all subdirectories.

Possible limitations imposed by the class loader hierarchy are listed here with suggested work-around solutions:

• Since the iPlanet Application Server Module Classloader and the iPlanet Application Server Application Classloader do not interact with each other, a J2EE application cannot load J2EE module classes (and vice versa). One way to circumvent this is to include the relevant path to the required class in the System Classpath, which will then cause it to be loaded by the System Classloader. For an example of this see the following sample:

  http://developer.iplanet.com/appserver/samples/pkging/docs/sampleC.html

• Since each J2EE application in iPlanet Application Server is loaded by its own classloader, two EAR files that are registered as applications cannot load classes from each other. This ensures that classes from two applications are loaded in isolation, which prevents two similarly named classes from different applications from overwriting each other in the classloader.

• There is only one iPlanet Application Server module classloader that loads all J2EE standalone modules. This allows two modules to interact with each other. However, this means that no two classes in a module should have the same name. For example, if ejb1.jar attempts to load com.samples.company.DBConnector and war1.war attempts to load com.samples.company.DBConnector, one will overwrite the other.

  
  

  ---

  Tip

  Because there is only one classloader for all standalone modules, there is a potential security risk if you allow classes from one module to be accessed by all of the other standalone modules. Therefore, it is a good idea to include in standalone modules only reusable components that everyone is allowed to access.

  ---

  
  

  
  

  ---

  Note

  A resource such as a file that is accessed by a servlet, JSP, or EJB must be in a directory pointed to by the classloader's classpath. For example, the web class loader's classpath includes these directories: module_name/WEB-INF/classes module_name/WEB-INF/compiled_jsp module_name/WEB-INF/lib If a servlet accesses a resource, it must be in one of these directories or it will not be loaded properly.

  ---

  
  

Dynamic Reloading

---

Servlets, JSPs, and EJBs can be dynamically reloaded while the server is running. This allows you to change module and application code and descriptors without restarting the server. This is useful in a development environment, because it allows code changes to be tested quickly.

Dynamic reloading is not recommended for a production environment, however, because it may degrade performance. In addition, whenever a reload is done, the sessions at that transit time become invalid. The client must restart the session.

Enabling Dynamic Reloading

Dynamic reloading for all classes can be turned on or off using the following registry entry:

SYSTEM_JAVA\Versioning\Disable

By default it is set to 1, indicating that dynamic reloading is disabled. A value of 0 enables dynamic reloading.

You can edit the registry using the kregedit tool. For more information, see the Administrator's Guide.

Dynamic Reloading of Servlets and JSPs

Dynamic reloading, when enabled, is built into the server for servlets and JSPs. Changes made while the iPlanet Application Server is running are picked up the next time a request arrives for that servlet or JSP.

Dynamic Reloading of EJBs

Dynamic reloading, when enabled, is built into the server for EJBs. Changes made while the iPlanet Application Server is running are picked up the next time a request arrives for that EJB.

However, an EJB's interfaces and helper classes are not dynamically reloadable, so if you change them, you must restart the server.

If an EJB changes during a session, the EJB Container serializes the states of the EJB instances involved in the session and deserializes them after recreating the pool of instances.

---

Note	If you have migrated from iPlanet Application Server 6.0 SP2 to SP3 or SP4, you must regenerate the stubs for your EJBs, or dynamic reloading of the EJB implementation classes won't work. If you don't regenerate the stubs, only servlets and JSPs are dynamically reloaded.

---