Overview of 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 stand-alone applications:
- An Enterprise JavaBean (EJB) JAR file
- A Web application WAR file
- A resource adapter RAR file
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.
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.
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.
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.
The following graphic illustrates this WebLogic Server application classloading concept.
Figure- 1 WebLogic Server Classloading
If your application includes servlets and JSPs that use EJBs:
- Package the servlets and JSPs in a WAR file
- Package the Enterprise JavaBeans in an EJB JAR file
- Package the WAR and JAR files in an EAR file
- Deploy the EAR file
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.
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.
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.
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.
For simplicity, JSP classloaders are not described in the following diagram.
Figure-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.
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
Declaring the Classloader Hierarchy
You can declare the classloader hierarchy in the WebLogic-specific application deployment descriptor weblogic-application.xml.
The DTD for this declaration is as follows:
- <!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):
<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>
Figure-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.
If you use a custom classloader hierarchy, servlet reloading is disabled for Web applications in that particular application.
Nesting is limited to three levels (including the application classloader). Deeper nestings lead to a deployment exception.
Custom classloader hierarchies are currently restricted to Web and EJB modules.
Duplicate entries lead to a deployment exception.
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.
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.
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.
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 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:
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:
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.
Mild Deployment - Subset of Hot Deployment
From last few days I was trying to incorporate Hot Deployment functionality into my application, to reduce the deployment time and also to elevate the performance. Due to some flaws in the design, I was not able to incorporate it “PROPERLY”. Yes you heard correct - “not Properly”.
Ok let me take a step back. Let’s first answer the question – What is Hot Deployment? In very simple terms – Hot deployment is a feature which allows developers to deploy .class/.jsp files without shutting down the server. To see the changes you just have to refresh the application.
JSPs can be hot deployed easily. You just have to replace the newer version of your JSP in the build folder. Why? Answer is very simple. There is a separate Classloader for loading Web Application.
Note: Whenever an application is deployed in the Weblogic Application Server using the exploded (-x) option, a temporary build folder is generated.
But what about .class files? Once you make some changes in a .java file what process you follow? Usually we follow these steps:
- Fist shutdown the server.
- Compile the file.
- Deploy the application again.
- Then in the end start the application server.
If you observe, whenever you deploy the application, it deletes the domain folder and creates it from the scratch. This process usually takes around 3-5 minutes. domain folder also contains JSPs. So if you have hot deployed any of your JSPs, all changes are gone.
Note: domain folder is also a temporary folder under the build folder. domain folder usually contains compiled JSPs.
To address these issues, I came up with a new feature – “Mild Deployment”. It is a kind of Hot Deployment, but in this case you have to shutdown the application server. This feature will eliminate the re-deployment of the application and will save lot of time.
What is Mild Deployment? Before answering this question let me give you some brief about Weblogic Deployment Process. There are two ways to deploy an application in Weblogic – archival deployment and exploded deployment. The only difference between these two is, in the later one the EAR file is exploded into the appropriate directory structure.
Now coming back to the original question – What is Mild deployment? In the Mild Deployment we replace the respective JAR files, which are generated temporarily in the build folder as a result of explosion of the EAR file. This feature does not work if the application is deployed using the archival mode.
Posts
No comments:
Post a Comment