WebLogic类加载过程简述

WebLogic类加载过程
王明杰
20061012 19:28-21:59
英文水平有限，翻译的肯定有不对的地方，欢迎指正。

希望能够各位同事在使用weblogic的过程中带来帮助。

小注：
2006-10-12 下午，在weblogic中部署一个启动类，部署了近2个小时，weblogic总是提示“找不到类的异常”。

心情很是郁闷。

“大事问老婆，小事问goole”，一个字“搜”。

终于找到了WebLogic的官方文档，摘录下来，进行了翻译，终于对WebLogic的类的加载过程有了比较系统的了解。

希望该文档能够帮助和我有同样疑惑的人走出困境，共同进步！！！
V ersion 0.1
msn:wangmingjie_2002@
官方原版
（19：30开始）20061012开始
WebLogic Server Application Classloading
The following sections provide an overview of Java classloaders, followed by details about WebLogic Server J2EE application classloading.
下面的部分概况的介绍了java的类装载器，接着详细的介绍了WebLogicJ2EE
应用服务器（WebLogic Server J2EE application ）的类装载过程。

▪Java Classloader Overview java类转载器综述
▪WebLogic Server Application Classloader Overview WebLogic 应用服务器类装载器介绍。

▪Resolving Class References Between Modules and Applications
Java Classloader Overview
Classloaders are a fundamental module of the Java language. A classloader is a part of the Java virtual machine (JVM) that loads classes into memory;
a classloader is responsible for finding and loading class files at run time. Every successful Java programmer needs to understand classloaders and their behavior. This section provides an overview of Java classloaders.
类装载器是java语言的一个基本模块，类装载器是java虚拟机的一部分，把相应的类装载到内存中，类装载器负责在运行期间找到类并载入类。

每个成功的java程序员都需要理解java类装载器及其行为。

本部分综述了java类装载器。

Java Classloader Hierarchy java类装载器的层次
Classloaders contain a hierarchy with parent classloaders and child classloaders. The relationship between parent and child classloaders is analogous to the object relationship of super classes and subclasses. The bootstrap classloader is the root of the Java classloader hierarchy. The Java virtual machine (JVM) creates the bootstrap classloader, which loads the Java development kit (JDK) internal classes and java.* packages included in the JVM. (For example, the bootstrap classloader loads ng.String.)
类装载器有层次，包含了父装载器和子装载器。

父装载器和子装载器直接的关系和java中的父类和子类的关系是相似的。

启动类装载器是根类装载器，它将jdk 的内部类和包含在java.*包中的类装载到java虚拟机。

（例如：启动类装载器载入ng.String类。

）
The extensions classloader is a child of the bootstrap classloader. The extensions classloader loads any JAR files placed in the extensions directory of the JDK. This is a convenient means to extending the JDK without adding entries to the classpath. However, anything in the extensions directory must be self-contained and can only refer to classes in the extensions directory or JDK classes.
（C:\j2sdk1.4.2_08\jre\lib\ext）
扩这的类装载器是启动类装载器的子类装载器。

扩展类装载器会自动加载放在jdk扩展文件夹中的jar包。

这很方便，意味着扩展JDK不需要
向classpath中增加信息。

然而扩展文件夹中的任何包都必须独立，只能参照扩展文件夹中的类或者JDK的类。

（最后这句翻译的不好。

）
The system classpath classloader extends the JDK extensions classloader. The system classpath classloader loads the classes from the classpath of the JVM. Application-specific classloaders (including WebLogic Server classloaders) are children of the system classpath classloader.
系统classpath类装载器继承了JDK扩展类装载器。

系统类装载器从JVM指定的应用类装载器（系统装载器的子类装载器）的classpth来加载类。

Note: What BEA refers to as a "system classpath classloader" is often referred to as the "application classloader" in contexts outside of WebLogic Server. When discussing classloaders in WebLogic Server, BEA uses the term "system" to differentiate from classloaders related to J2EE applications (which BEA refers to as "application classloaders").
注意：在WebLogic应用服务器之外，BEA中说的“系统classpth类装载器”也称为“应用类装载器”。

在weblogic中讨论类装载器的时候，BEA使用的术语“系统”和J2EE应用服务器的类装载器（BEA称之为“应用类装载器”）是有区别的。

Loading a Class
Classloaders use a delegation model when loading a class. The classloader implementation first checks its cache to see if the requested class has already been loaded. This class verification improves performance in that its cached memory copy is used instead of repeated loading of a class from disk. If the class is not found in its cache, the current classloader asks its parent for the class. Only if the parent cannot load the class does the classloader attempt to load the class. If a class exists in both the parent and child classloaders, the parent version is loaded. This delegation model is followed to avoid multiple copies of the same form being loaded. Multiple copies of the same class can lead to a ClassCastException.
类装载器使用代理模式来装载一个类。

子类装载器时候从它的缓存中检查被请求的类是否已经装载。

类被缓存在内存中而不是重复的从
硬盘上读取，这样可以提高类的校验效率。

如果被请求的类不在它的缓存中，那么当前的类装载器就请求它的父类来装载这个类。

当父
类装载器无法找到请求的类，那么子类装载器才试图去装载这个类。

如果一个类既在父类装载器中又在子类装载器中，那么父类装载器
中的类会被加载。

代理模式可以防止同样的类被多次装载。

多次装载相同的类会产生ClassCastException异常。

Classloaders ask their parent classloader to load a class before attempting to load the class themselves. Classloaders in WebLogic Server that are associated with Web applications can be configured to check locally first before asking their parent for the class. This allows Web applications to use their own versions of third-party classes, which might also be used as part of the WebLogic Server product. The
prefer-web-inf-classes Element section discusses this in more detail.
类装载器在自己装载请求类之前，先请求他们的父类装载器来装载此类。

（父类找不到，才自己装载请求类）weblogic服务器中和web应用关联的类装载器可以配置先从自己的类装载器中找到请求的类，如果找不到在请求父类。

这就允许
web应用使用他们自己的第三方类库，这些类库也被weblogic应用服务器产品使用。

在章节prefer-web-inf-classes Element中会详细讨论。

prefer-web-inf-classes Element
The weblogic.xml Web application deployment descriptor contains a prefer-web-inf-classes element (a sub-element of the
container-descriptor element). By default, this element is set to False. Setting this element to True subverts the classloader delegation model so that class definitions from the Web application are loaded in preference to class definitions in higher-level classloaders. This allows a Web application to use its own version of a third-party class, which might also be part of WebLogic Server. See weblogic.xml Deployment Descriptor Elements.
在web应用部署描述文件weblogic.xml 中，包含了元素
prefer-web-inf-classes （container-descriptor 元素的子元素）。

默认值被设置为false。

设置这个元素的值未true，从来改变类装载器的代理模式，提升子类装载器的级别，定义为首先从web应用中加载类。

（然后从父类装载器中加载类）。

这允许web应用来使用他们自己的第三方类库，这些类库也可能是weblogic应用服务器的。

See weblogic.xml Deployment Descriptor Elements.
When using this feature, you must be careful not to mix instances created from the Web application's class definition with issuances created from the server's definition. If such instances are mixed, a ClassCastException results.
当使用这一特性的时候，你必须小心，不要web应用的类的实例和服务器定义的实例混淆。

否则就会产生ClassCastException 异常。

Listing 4-1 illustrates the prefer-web-inf-classes element, its description and default value.
列表4-1，举例说明了prefer-web-inf-classes元素，有详细描述和默认值。

Listing 4-1 prefer-web-inf-classes Element
/**
* If true, classes located in the WEB-INF directory of a web-app will be loaded in preference to classes loaded in the application or system classloader.
* @default false
*/
boolean isPreferWebInfClasses();
void setPreferWebInfClasses(boolean b);
Changing Classes in a Running Program
WebLogic Server allows you to deploy newer versions of application modules such as EJBs while the server is running. This process is known as hot-deploy or hot-redeploy and is closely related to classloading.
WebLogic Server 在运行的时候允许你重新部署新的类，例如ejbs。

这就是热部署或者热重新部署，是和类加载过程紧密相关的。

Java classloaders do not have any standard mechanism to undeploy or unload a set of classes, nor can they load new versions of classes. In order to make updates to classes in a running virtual machine, the classloader that loaded the changed classes must be replaced with a new classloader. When a classloader is replaced, all classes that were loaded from that classloader (or any classloaders that are offspring of that classloader) must be reloaded. Any instances of these classes must be re-instantiated.
java的类装载器没有任何标准机制来重新部署或者装载类，或者装载新版本的类。

因此为了能够在jvm运行的时候更新类，重新装载被改变的类就必须使用一个新的类装载器将原来的类装载器替换掉。

当类装载器被替换，所有的已经被替换的类装载器装载的类（包括它的子类装载器装载的类）都必须重新装载。

所有这些类的实例必须被重新实例化。

In WebLogic Server, each application has a hierarchy of classloaders that are offspring of the system classloader. These hierarchies allow applications or parts of applications to be individually reloaded without affecting the rest of the system. WebLogic Server Application Classloader Overview discusses this topic.
在WebLogic Server，每个应用都有系统类装载器的一系列子类装载器。

这种机制允许应用程序或应用程序中的独自重新装载类而不影响系统的其他部分。

章节WebLogic Server Application Classloader Overview讨论这个主题。

WebLogic Server Application Classloader Overview
This section provides an overview of the WebLogic Server application classloaders.
本章节给出了WebLogic Server 应用类装载器的总的描述。

Application Classloading
WebLogic Server classloading is centered on the concept of an application. An application is normally packaged in an Enterprise Archive (EAR) file containing application classes. Everything within an EAR file is considered part of the same application. The following may be part of an EAR or can be loaded as standalone applications:
▪An Enterprise JavaBean (EJB) JAR file
▪A Web application WAR file
▪A resource adapter RAR file
WebLogic Server类装载过程是应用概念中的中心。

一个应用通常是一个EAR文件，它包含应用classes。

EAR文件中所有的文件都被认为是应用的一部分。

下面的是是EAR的一部分，或者能够被应用程序独自加载。

∙EJB jar文件
∙WAR文件
∙包含资源适配器的RAR文件（这些都可以被应用单独加载，也可以是EAR的一部分）
Note: For information on Resource Adapters and classloading, see About Resource Adapter Classes.
注意：关于资源适配器的信息和加载过程，请看About Resource Adapter Classes.
If you deploy an EJB and a Web application separately, they are considered two applications. If they are deployed together within an EAR file, they are one application. You deploy modules together in an EAR file for them to be considered part of the same application.
如果你单独的部署了EJB和WEB应用，那么他们被认为是两个应用，如果他们通过一个EAR文件同时部署，那么他们被认为是一个应用。

你部署了一个EAR文件，那么其中所有的模块都被认为是一个应用。

Every application receives its own classloader hierarchy; the parent of this hierarchy is the system classpath classloader. This isolates applications so that application A cannot see the classloaders or classes of application B. In hierarchy classloaders, no sibling or friend concepts exist. Application code only has visibility to classes loaded by the classloader associated with the application (or module) and classes that are loaded by classloaders that are ancestors of the application (or module) classloader. This allows WebLogic Server to host multiple isolated applications within the same JVM.
每个应用接受他们自己的有继承关系的多个类装载器；这些类装载器的父类装载器就是系统classpath装载器。

（呵呵，所以在classpath中设置的类可以被所有的应用使用。

明白了这些就可以重构我们的部署，使jar包变的清晰明了。

）因此独立的应用a是不能看到B的类装载器和classes的。

从类的装载器继承关系上看，没有兄弟或者友元的概念存在。

应用程序代码仅能访问被和本应用或者模块相关的类装载器装载的类，还有被这些类装载器的父类装载器装载的类。

这就允许weblogic服务器在同一个JVM下处理多个独立的应用。

Application Classloader Hierarchy 应用类装载器层次关系
WebLogic Server automatically creates a hierarchy of classloaders when an application is deployed. The root classloader in this hierarchy loads any EJB JAR files in the application. A child classloader is created for each Web application WAR file.
weblogic Server自动建立类装载器层次当一个应用被部署的时候。

层次中的根类装载器装载应用中所有EJB jar包中的文件，每个web应用（WAR）都会创建一个子类装载器。

Because it is common for Web applications to call EJBs, the WebLogic Server application classloader architecture allows JavaServer Page (JSP) files and servlets to see the EJB interfaces in their parent classloader. This architecture also allows Web applications to be redeployed without redeploying the EJB tier. In practice, it is more common to change JSP files and servlets than to change the EJB tier.
因为web应用调用ejb很平常，weblogic应用服务器的类装载器架构允许jsp
和servlet可以在他们的父类装载器中访问ejb接口。

这个架构同样允许web
应用重新部署的时候不需要重新部署ejb。

实际上，改写jsp和servlet比改写ejb更普遍。

The following graphic illustrates this WebLogic Server application classloading concept.
Figure 4-1 WebLogic Server Classloading
If your application includes servlets and JSPs that use EJBs:
▪Package the servlets and JSPs in a W AR file
▪Package the Enterprise JavaBeans in an EJB JAR file
▪Package the W AR and JAR files in an EAR file
▪Deploy the EAR file
（EAR中包含EJB JAR和WAR，WAR中包含jsp和servlet。

）
Although you could deploy the WAR and JAR files separately, deploying them together in an EAR file produces a classloader arrangement that allows the servlets and JSPs to find the EJB classes. If you deploy the WAR and JAR files separately, WebLogic Server creates sibling classloaders for them. This means that you must include the EJB home and remote interfaces in the WAR file, and WebLogic Server must use the RMI stub and skeleton classes for EJB calls, just as it does when EJB clients and implementation classes are in different JVMs. This concept is discussed in more detail
in the next section Application Classloading and Pass-by-Value or Reference.
虽然你可以单独的部署WAR和JAR文件，但是将他们一块部署到一个EAR好处多多，可以允许servlet和jsp访问ejb的类。

如果你将WAR和JAR单独部署了，那么weblogic服务器会创建兄弟类装载器。

（创建两个并行的类装载器，没有继承关系）这就意味着你必须在你的WAR包中包含EJB的home和remote interface 。

weblogic服务器使用RMI技术来访问EJB，就和EJB客户端和实现类在不同的JVM中一样。

（换句话说，效率和访问机制都不同了。

）这些概念会在下个章节Application Classloading and Pass-by-Value or Reference.中纤细讨论。

Note: The Web application classloader contains all classes for the Web application except for the JSP class. The JSP class obtains its own classloader, which is a child of the Web application classloader. This allows JSPs to be individually reloaded.
注意：Web应用类装载器包含除了jspclass之外的所有class，也就是说jsp
有自己的类装载器，它的父类装载器是WAR类装载器。

这就允许jsp被单独装载。

Custom Module Classloader Hierarchies 自定义模块类装载器层次关系
You can create custom classloader hierarchies for an application allowing for better control over class visibility and reloadability. You achieve this by defining a classloader-structure element in the
weblogic-application.xml deployment descriptor file.
你为一个应用可以创建自定义的类装载器层次管理，以便更好的丛刊类的可见性和重新装载的能力。

你通过在weblogic-application.xml 定义元素classloader-structure来构建。

The following diagram illustrates how classloaders are organized by default for WebLogic applications. An application level classloader exists where all EJB classes are loaded. For each Web module, there is a separate child classloader for the classes of that module.
下图详细说明了类装载器是如何被weblogic应用默认组织的。

所有ejb类被装载时应用层的类装载器已经存在。

每个WEB模块，都有一个子类装载器。

For simplicity, JSP classloaders are not described in the following diagram.
为了简化，jsp类装载器不在下图中。

Figure 4-2 Standard Classloader Hierarchy
This hierarchy is optimal for most applications, because it allows call-by-reference semantics when you invoke EJBs. It also allows Web modules to be independently reloaded without affecting other modules. Further, it allows code running in one of the Web modules to load classes from any of the EJB modules. This is convenient, as it can prevent a Web module from including the interfaces for EJBs that is uses. Note that some of those benefits are not strictly J2EE-compliant.
对于大多数应用来说这个层次是比较理想的，因为它允许参照调用ejb（不需要rmi）。

它也允许web模块独立的重新装载而不影响其他模块，进一步说，它允许在一个web模块中运行的代码调用任何ejb模块。

这个很方便，不需要web
模块包含ejb的interface类。

注意这些好处并不全部严格遵循J2EE规范。

The ability to create custom module classloaders provides a mechanism to declare alternate classloader organizations that allow the following:
▪Reloading individual EJB modules independently
▪Reloading groups of modules to be reloaded together
▪Reversing the parent child relationship between specific Web modules and EJB modules ▪Namespace separation between EJB modules
（21:52结束,水平有限接近两个半小时才翻译了一半，希望能够各位
同事在使用WebLogic的时候带来帮助。

:) ）
Declaring the Classloader Hierarchy 声明类装载器层次关系（用户
可以自己定制，个人观点了解即可）
You can declare the classloader hierarchy in the WebLogic-specific application deployment descriptor weblogic-application.xml. For instructions on how to edit deployment descriptors, refer to the WebLogic Builder Online Help.
The DTD for this declaration is as follows:
Listing 4-2 Declaring the Classloader Hierarchy
<!ELEMENT classloader-structure (module-ref*, classloader-structure*)>
<!ELEMENT module-ref (module-uri)>
<!ELEMENT module-uri (#PCDATA)>
The top-level element in weblogic-application.xml includes an optional classloader-structure element. If you do not specify this element, then the standard classloader is used. Also, if you do not include a particular module in the definition, it is assigned a classloader, as in the standard hierarchy. That is, EJB modules are associated with the application Root classloader, and Web application modules have their own classloaders.
The classloader-structure element allows for the nesting of classloader-structure stanzas, so that you can describe an arbitrary hierarchy of classloaders. There is currently a limitation of three levels. The outermost entry indicates the application classloader. For any modules not listed, the standard hierarchy is assumed.
Note: JSP classloaders are not included in this definition scheme. JSPs are always loaded into a classloader that is a child of the classloader associated with the Web module to which it belongs.
For more information on the DTD elements, refer to Enterprise Application Deployment Descriptor Elements.
The following is an example of a classloader declaration (defined in the classloader-structure element in weblogic-application.xml):
Listing 4-3 Example Classloader Declaration
<classloader-structure>
<module-ref>
<module-uri>ejb1.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web3.war</module-uri>
</module-ref>
<classloader-structure>
<module-ref>
<module-uri>web1.war</module-uri>
</module-ref>
</classloader-structure>
<classloader-structure>
<module-ref>
<module-uri>ejb3.jar</module-uri>
</module-ref>
<module-ref>
<module-uri>web2.war</module-uri>
</module-ref>
<classloader-structure>
<module-ref>
<module-uri>web4.war</module-uri>
</module-ref>
</classloader-structure>
<classloader-structure>
<module-ref>
<module-uri>ejb2.jar</module-uri>
</module-ref>
</classloader-structure>
</classloader-structure>
</classloader-structure>
The organization of the nesting indicates the classloader hierarchy. The above stanza leads to a hierarchy shown in the following diagram.
Figure 4-3 Example Classloader Hierarchy
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 J2EE 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 BEA 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 calling modules.
There are some restrictions to creating user-defined module classloader hierarchies; these are discussed in the following sections.
Servlet Reloading Disabled
If you use a custom classloader hierarchy, servlet reloading is disabled for Web applications in that particular application.
如果自定义，那么servlet 重新装载失效。

Web Applications prefer-web-inf-classes Flag Ignored
If you use a custom classloader hierarchy, the
prefer-web-inf-classes flag will be ignored for web applications within that hierarchy.
Custom Classloader Structure with Iterative Development
When a new classloader-structure element is added as a leaf node anywhere in the existing class-loader hierarchy, then the module added to the new classloader-structure can be deployed without redeploying the entire application. However, when deleting or rearranging the existing classloader-structure element within the hierarchy, the entire application should be redeployed.
When you add new module-uri(s) to an existing classloader-stucture, ensure that it is added only after the existing module-uri(s). New module(s) can be deployed without redeploying the entire application. However, when moving or deleting module-uri(s) across
classloader-stucture elements, ensure that you redeploy the entire application.
Nesting Depth
Nesting is limited to three levels (including the application classloader). Deeper nestings lead to a deployment exception.
Module Types
Custom classloader hierarchies are currently restricted to Web and EJB modules.
Duplicate Entries
Duplicate entries lead to a deployment exception.
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 callee's 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.
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.
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 occuring while a change is being made) might end up accessing different versions of classes depending on timing.
Development Use Only
The development-use-only feature is intended for development use. Because updates are not atomic, this feature is not suitable for production use. Individual EJB Classloader for Implementation Classes
WebLogic Server allows you to reload individual EJB modules without requiring you to reload other modules at the same time and having to redeploy the entire EJB module. This feature is similar to how JSPs are currently reloaded in the WebLogic Server servlet container.
Because EJB classes are invoked through an interface, it is possible to load individual EJB implementation classes in their own classloader. This way, these classes can be reloaded individually without having to redeploy the entire EJB module. Below is a diagram of what the classloader hierarchy for a single EJB module would look like. The module contains two EJBs (Foo and Bar). This would be a sub-tree of the general application hierarchy described in the previous section.
Figure 4-4 Example Classloader Hierarchy for a Single EJB Module
To perform a partial update of files relative to the root of the exploded application, use the following command line:
Listing 4-4 Performing a Partial File Update
java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy myejb/foo.class
After the -redeploy command, you provide a list of files relative to the root of the exploded application that you want to update. This might be the path to a specific element (as above) or a module (or any set of elements and modules). For example:
Listing 4-5 Providing a List of Relative Files for Update
java weblogic.Deployer -adminurl url -user user -password password
-name myapp -redeploy mywar myejb/foo.class anotherejb
Given a set of files to be updated, the system tries to figure out the minimum set of things it needs to redeploy. Redeploying only an EJB impl class causes only that class to be redeployed. If you specify the whole EJB (in the above example, anotherejb) or if you change and update the EJB home interface, the entire EJB module must be redeployed.
Depending on the classloader hierarchy, this redeployment may lead to other modules being redeployed. Specifically, if other modules share the EJB classloader or are loaded into a classloader that is a child to the
EJB's classloader (as in the WebLogic Server standard classloader module) then those modules are also reloaded.
Application Classloading and Pass-by-Value or Reference
Modern programming languages use two common parameter passing models: pass-by-value and pass-by-reference. With pass-by-value, parameters and return values are copied for each method call. With pass-by-reference, a pointer (or reference) to the actual object is passed to the method. Pass by reference improves performance because it avoids copying objects, but it also allows a method to modify the state of a passed parameter.
WebLogic Server includes an optimization to improve the performance of Remote Method Interface (RMI) calls within the server. Rather than using pass by value and the RMI subsystem's marshalling and unmarshalling facilities, the server makes a direct Java method call using pass by reference. This mechanism greatly improves performance and is also used for EJB 2.0 local interfaces.
RMI call optimization and call by reference can only be used when the caller and callee are within the same application. As usual, this is related to classloaders. Because applications have their own classloader hierarchy, any application class has a definition in both classloaders and receives a ClassCastException error if you try to assign between applications. To work around this, WebLogic Server uses call-by-value between applications, even if they are within the same JVM.
Note: Calls between applications are slower than calls within the same application. Deploy modules together as an EAR file to enable fast RMI calls and use of the EJB 2.0 local interfaces.
Resolving Class References Between Modules and Applications
Your applications may use many different Java classes, including enterprise beans, servlets and JavaServer Pages, utility classes, and
third-party packages. WebLogic Server deploys applications in separate classloaders to maintain independence and to facilitate dynamic redeployment and undeployment. Because of this, you need to package your application classes in such a way that each module has access to the classes it depends on. In some cases, you may have to include a set of classes in more than one application or module. This section describes how WebLogic Server uses multiple classloaders so that you can stage your applications successfully.
About Resource Adapter Classes
With this release of WebLogic Server, each resource adapter now uses its own classloader to load classes (similar to Web applications). As a result, modules like Web applications and EJBs that are packaged along with a resource adapter in an application archive (EAR file) do not have visibility into the resource adapter's classes. If such visibility is required, you must place the resource adapter classes in APP-INF/classes. You can also archive these classes (using the JAR utility) and place them in the APP-INF/lib of the application archive.
Make sure that no resource-adapter specific classes exist in your WebLogic Server system classpath. If you need to use resource adapter-specific classes with Web modules (for example, an EJB or Web application), you must bundle these classes in the corresponding module's archive file (for example, the JAR file for EJBs or the WAR file for Web applications).
Packaging Shared Utility Classes
WebLogic Server provides a location within an EAR file where you can store shared utility classes. Place utility JAR files in the APP-INF/lib directory and individual classes in the APP-INF/classes directory. (Do not place JAR files in the /classes directory or classes in the /lib directory.) These classes are loaded into the root classloader for the application.
This feature obviates the need to place utility classes in the system classpath or place classes in an EJB JAR file (which depends on the standard WebLogic Server classloader hierarchy). Be aware that using this feature is subtly different from using the manifest Class-Path described in the following section. With this feature, class definitions are shared across the application. With manifest Class-Path, the classpath of the referencing module is simply extended, which means that separate copies of the classes exist for each module.。