WebSphere Application Server V4.0 classloader changed; module visibility deprecated in V4.0.3
 Technote (FAQ)
 
Problem
WebSphere® Application Server's module visibility feature can still be used, but has been deprecated. There is a new classloader visibility feature: J2EE™ application visibility.
 
Solution
The following is copied from the WebSphere Application Server V4.0.3 Release Notes:

  • Module visibility is deprecated. It is recommended that Application Servers using module visibility switch to using the new J2EE application visibility.

  • Compatibility visibility has been changed as follows:

    • All EJB modules in the Server are loaded by the single EJB/Dependency classloader.

    • Dependencies (Manifest classpath entries) are loaded by the application's EJB/Dependency classloader. Dependencies are not reloadable, code changes made to dependent classes require a restart.

    • Each WAR module will receive its own classloader. The WAR classloader's parent is the EJB/Dependency loader.

  • Server visibility has been changed as follows:

    • There is a single classloader. All EJBs, WARs, and Dependencies (Manifest classpath entries) are loaded by this single classloader.

    • Classes are not reloadable, code changes require a restart.

  • Application visibility has been changed as follows:

    • There is a single classloader for each application. All EJBs, WARs, and Dependencies (Manifest classpath entries) are loaded by this single classloader.

    • Changes to WAR modules will automatically cause the application to restart, reloading all classes.

  • A new J2EE Application visibility is available. This is the recommended visibility. To get this new visibility, add a new System Property with Name com.ibm.ws.classloader.J2EEApplicationMode and Value true on the JVM Settings tab of the application server.

    • All EJB modules within an Application are loaded by a single EJB/Dependency application classloader.

    • Dependencies (Manifest classpath entries) are loaded by the application's EJB/Dependency classloader. The EJB/Dependency classloader is not automatically reloadable, code changes require a manual restart of the application.

    • Each WAR module will receive its own classloader. The WAR classloader's parent is the EJB/Dependency loader.

      • Classes inside of WAR modules are not visible to other WAR modules or EJB modules.

    • The default delegation mode for WAR modules is true. This means that classes inside of WAR files will not be loaded in preference to classes loaded by a parent classloader. To change the delegation add this system property "com.ibm.ws.classloader.warDelegationMode = false"

    • The default delegation mode for EJB modules is true. This means that classes inside of EJB modules or at the root of the EAR file will not be loaded in preference to classes loaded by a parent classloader. To change the delegation add this system property "com.ibm.ws.classloader.ejbDelegationMode = false"

V4.0.3 Release Notes: ftp://ftp.software.ibm.com/software/websphere/appserv/support/fixpacks/was40/fixpack3/docs/403RN.html

WebSphere Application Server V5.0 builds on this new classloader architecture.
 
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Java SDK
Operating system(s): HP-UX
Software version: 4.0.3
Software edition:
Reference #: 1052373
IBM Group: Software Group
Modified date: Dec 7, 2005