Understanding WebLogic Server Application Classloading 8-9
Figure 8–3 Example Classloader Hierarchy
8.2.5 User-Defined Classloader Restrictions
User-defined classloader restrictions give you better control over what is reloadable and provide inter-module class visibility. This feature is primarily for developers. It is
useful for iterative development, but the reloading aspect of this feature is not recommended for production use, because it is possible to corrupt a running
application if an update includes invalid elements. Custom classloader arrangements for namespace separation and class visibility are acceptable for production use.
However, programmers should be aware that the Java EE specifications say that applications should not depend on any given classloader organization.
Some classloader hierarchies can cause modules within an application to behave more like modules in two separate applications. For example, if you place an EJB in its own
classloader so that it can be reloaded individually, you receive call-by-value semantics rather than the call-by-reference optimization Oracle provides in our standard
classloader hierarchy. Also note that if you use a custom hierarchy, you might end up with stale references. Therefore, if you reload an EJB module, you should also reload
the calling modules.
There are some restrictions to creating user-defined module classloader hierarchies; these are discussed in the following sections.
8.2.5.1 Servlet Reloading Disabled
If you use a custom classloader hierarchy, servlet reloading is disabled for Web applications in that particular application.
8.2.5.2 Nesting Depth
Nesting is limited to three levels including the application classloader. Deeper nestings lead to a deployment exception.
8.2.5.3 Module Types
Custom classloader hierarchies are currently restricted to Web and EJB modules.
8-10 Developing Applications for Oracle WebLogic Server
8.2.5.4 Duplicate Entries
Duplicate entries lead to a deployment exception.
8.2.5.5 Interfaces
The standard WebLogic Server classloader hierarchy makes EJB interfaces available to all modules in the application. Thus other modules can invoke an EJB, even though
they do not include the interface classes in their own module. This is possible because EJBs are always loaded into the root classloader and all other modules either share that
classloader or have a classloader that is a child of that classloader.
With the custom classloader feature, you can configure a classloader hierarchy so that a callees classes are not visible to the caller. In this case, the calling module must
include the interface classes. This is the same requirement that exists when invoking on modules in a separate application.
8.2.5.6 Call-by-Value Semantics
The standard classloader hierarchy provided with WebLogic Server allows for calls between modules within an application to use call-by-reference semantics. This is
because the caller is always using the same classloader or a child classloader of the callee. With this feature, it is possible to configure the classloader hierarchy so that two
modules are in separate branches of the classloader tree. In this case, call-by-value semantics are used.
8.2.5.7 In-Flight Work
Be aware that the classloader switch required for reloading is not atomic across modules. In fact, updates to applications in general are not atomic. For this reason, it is
possible that different in-flight operations operations that are occurring while a change is being made might end up accessing different versions of classes depending
on timing.
8.2.5.8 Development Use Only
