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