Previous Contents Index Next |
iPlanet Application Server Developer's Guide |
Appendix B Runtime Considerations
This appendix convers the following topics:
Runtime Environments
Runtime Environments
Whether you register a component as a standalone module or as an application, registering affects both the file system and the registry. Figure B-1 shows the standalone module runtime environment. Figure B-2 shows the application runtime environment.
Standard 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.5\J2EE-Module\module_name
Tip All standalone 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    Standalone 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.5\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
A delegation design is used to load classes and resources at runtime. In this delegation design, each instance of a class loader has an associated parent class loader, which could be either a system class loader or another custom classloader.
When called upon to to find a class or resource, a class loader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resources itself. If the parent classloader can't load a class, a method, called findClass (), is called on the custom class loader.
In effect, the custom class loader 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, i.e from the specified file system or from the network. Each class loader looks at a different repository for classes. The classloaders and the files they examine are described in Table B-1.
Possible limitations imposed by the class loader hierarchy are listed here with suggested work-around solutions:
Since the iPlanet Application Server ModuleClassloader, which is the class loader for all independent modules, and the iPlanet Application Server Application Classloader do not interact with each other, a J2EE application cannot load J2EE standalone module's 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 J2EE specs requires that one applcation should be able to access components in another application, each J2EE application in iPlanet Application Server is loaded by its own classloader and 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.
- One should however note that including the relavant path for the classes in the System Classpath exposes the classes to all the application deployed under Application Server which may compromise the Security requirements of the application.This also prevents classes to be reloadable, because classses in the System Classpath are loaded by the System classloader.
There is only one iPlanet Application Server ApplicationClassloader that is assigned to load all J2EE standalone modules. This allows two standalone modules to interact with each other. However, this means that no two classes in standalone modules 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.
Dynamic Reloading
Servlets, JSPs, and EJB implementation classes 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.
When dynamic reloading is disabled, only one Module Classloader or an Application Classloader are loaded.
Enabling Dynamic Reloading
Dynamic reloading for all classes can be turned on or off using the following two methods:
Select the application server instance in the left pane of the Administration Tool.
Click the Enable Dynamic Class Reloading checkbox.
Modifying the Registry
SYSTEM_JAVA\Versioning\DisableBy 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 create 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.
Limitations of Dynamic Reloading
If a J2EE component, that is Servlet or Ejb implememntaion class is being referred to directly from some other class, then the dynamic reloading for the module which the J2EE component being reffered belongs to would not work. For example creating a new instance of a Servlet/EJB implementation class from a helper class. J2EE does not recommend doing so.If one J2EE component is accessing a package access member(protected, this case arises when J2EE component and helper classes happens to be in the same package) of an helper class and if Dynamic reloading is enabled then IleegalAccesError occures. In this case Dynamic reloading has to be switched off.
Note If you have migrated from iPlanet Application Server 6.0 SPx to 6.5, you must regenerate the stubs for your EJBs, or dynamic reloading of the EJB implementation classes won't work.
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated March 06, 2002