Classloader J2EE rakendusserveris (Bea Weblogic Server, IBM WebSphere)

Tartu Ülikool Matemaatika-informaatika Teaduskond Referaat Classloader J2EE rakendusserveris (Bea Weblogic Server, IBM WebSphere) Autor: Madis Lunkov Inf II Juhendaja: Ivo Mägi Tartu 2005

Contents Contents... 2 Preface... 3 WebLogic Server Application Classloading... 4 Java Classloaders Overview... 4 WebLogic Server Application Classloader Overview... 4 Application Classloading... 4 Application Classloader Hierarchy... 5 Custom Module Classloader Hierarchies... 6 Declaring the Classloader Hierarchy... 6 User-Defined Classloader Restrictions... 7 Individual EJB Classloader for Implementation Classes... 7 Application Classloading and Pass-by-Value or Reference... 8 WebSphere Application Server... 9 Classloader Overview...9 Classloader Details... 10 Summary... 12 Used literature... 13

Preface In the most general sense, a server is a program that provides information to a client that requests that information. Sometimes a server is a computer used to centralize resources so that they can be shared by a number of different users. For instance, file servers centralize file storage, database servers centralize data storage, and web servers centralize the distribution of web content. In a similar vein, an application server centralizes key programming tasks. An application server is designed to make it easier for developers to focus on developing the business logic in their applications (usually through components) and to develop three-tier applications. Application servers connect database information (usually coming from a database server) and the end-user or client program (often running in a Web browser) with sophisticated features like Connection Management, Transaction Management, and Security Management. But application servers are not limited to these features. Depending on their usage, application servers also need to be scalable and robust. To address these requirements, many application servers offer additional features, such as clustering and failover, load balancing, and so on. Enterprise JavaBeans (EJB) is a technology for developing, assembling, deploying, and managing distributed applications in an enterprise environment. This basically means that EJB provides a Java framework for executing objects residing on different machines over a distributed network. This is a powerful capability: It enables a user to harness the power of different machines transparently, in a single application. 3

WebLogic Server Application Classloading Java Classloaders Overview 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. Classloaders contain a hierarchy with parent classloaders and child classloaders. The bootstrap classloader is the root of the Java classloader hierarchy, which is created by JVM. 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. 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 are children of the system classpath classloader. When loading a Class classloaders use a delegation model, first checking its cache to see if the requested class has already been loaded. If the class is not found in its cache, the current classloader asks its parent for 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. The weblogic.xml Web application deployment descriptor contains a prefer-web-infclasses element (a sub-element of the container-descriptor element). By default, this element is set to False WebLogic Server allows deploy newer versions of application modules such as EJBs while the server is running. This process is known as hot-deploy or hot-redeploy. WebLogic Server Application Classloader Overview 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 When 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. When 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 one application cannot see the classloaders or classes of other application. 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. 4

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

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 classloaderstructure 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. 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. 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. <!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 classloaderstructure 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. 6

User-Defined Classloader Restrictions User-defined classloader restrictions give you better control over what is reloadable and provide inter-module class visibility. 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 it is adviseble use a custom hierarchy, to not end up with stale references. But when we reload an EJB module, we should also reload calling modules. Individual EJB Classloader for Implementation Classes WebLogic Server allows to reload individual EJB modules without requiring 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. 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. Example Classloader Hierarchy for a Single EJB Module 7

Application Classloading and Pass-by-Value or Reference Modern programming languages use two common parameter passing models: pass-byvalue 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. 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. 8

WebSphere Application Server Classloader Overview There are several different classloaders provided by the JVM and WebSphere Application Server, forming a calssloader hierarchy with classloaders having a parent classloader. The root classloader has no parent classloader. In classloader hiararchy, a request to load a class can go from a child classloader to a parent classloader but never from a parent classloader to child classloader. If a class is not found by a specific classloader or any of its parent classloaders, then a class not faound excepiton will result. Java classloading allows for a search mode that lets a classloader search its own class path before requesting a parent classloader or search via the parent classloader before its local class path. These searches, or delegation modes, are PARENT_LAST and PARENT_FIRST respectively. The JVM will cache the class on a successful load and will associate the class with its specific classloader. Classloaders are organized in a hierarchy. This means that a child classloader can delegate class finding and loading to its parent, should it fail to load a class. The root of the hierarchy is occupied by the JVM classloader and its Bootstrap classloader that loads the JVM classes. The JVM classloader loads the JVM classes, the JVM extension classes, and the classes defined in the classpath environment variable. WebSphere Extension classloader loads all WebSphere Application Server classes, resource adapters, and other classes. WebSphere Application Server application classloader loads classes from the WebSphere Application Server library application directory. WebSphere Application Server Server classloader loads shared libraries that are defined at the server level and can be accessed by all applications. The last classloader is the Application classloader that loads the J2EE applications. It has several options and class loading policies. Providing this hierarchy allows for the flexibility that may be required by a set of applications. In most cases, use of the default classloader and options are sufficient. In WebSphere Application Server, shared libraries provide a better mechanism where only applications that need the JARs are exposed to them. Other applications are not affected by the shared libraries. Shared libraries can be associated with one or more applications running within the Application Server. The advantage of using an application-scoped shared library, is the capability of using different versions of common application artifacts by different applications. A unique shared library can be defined for each version of a particular artifact, for example, a utility JAR. If a native library loaded by shared library requires a second native library, then it must not be specified in the shared library path. Rather it must be specified in the JVM native library path and will be loaded by the JVM classloader. Native libraries are loaded by Java using the System load library method. They are loaded on demand, when needed. Native libraries could be located in the JVM classloader or one of the WebSphere Application Server classloaders, the Extension, Server, or the Application module classloader. WebSphere Application Server Extensions, Server, and Application module classloaders define a local native library path, similar to the java.library.path supported by the JVM classloader. 9

Classloader Details At the root of the classloader hierarchy is the JVM classloader. This classloader loads the JVM Boot strap libraries, JVM extension libraries and the JVM System classloader in that order. In this classloader, there is no choice of delegation or search mode. These classes get unloaded when the Application server is stopped. Although it is possible to add your own classes to the JVM class path for classes that are used across multiple applications, but there are better solutions, such as using Shared libraries. The WebSphere Extension classloader primary responsibility is to load the WebSphere classes There are also the WebSphere lib/app classloader usin this class is not recommended. The WebSphere Server classloader is used when creating server scoped shared libraries. Shared libraries is a mechanism to specify class libraries and native libraries that are needed by one or more applications in a server. Once the shared library is defined, you can then associate one or more applications with the Shared library. If you would like to associate the shared libraries with all the applications in a server, that can be done by defining the shared library under the Server classloader. Multiple Server classloaders can be defined, forming a hierarchy of server classloaders. You can set the delegation mode for each of the Server classloaders to be parent first or parent last. The Application classloader, which is responsible for loading the J2EE applications, have two sub classloaders. The first one is the Application Module classloader, responsible for loading all application modules, with the potential exception of the Web Modules. The second one is the Web Module classloader that is lower in the classloader hierarchy and is responsible for loading the Web modules. The Web Module classloader is optional and is created for an application only in certain configurations. In both these classloaders, the search or delegation mode can be configured to be parent first or parent last. Options of the Application Classloader, known as the classloader isolation policies. There are two options: The first one defines whether there will be a single Application module classloader for the entire Application Server that will serve all the applications or a separate Application Module classloader for each application within the server. These are defined at the Application Server level, as Single or Multiple. A Web module of the application can have its own separate classloader at a lower hierarchy than the application Module classloader. This option is defined for each application. The first option is Application, indicating that for that application, there should not a separate Web module classloader, and that the Web modules be loaded by the application module classloader. The second option is Module, meaning for that application, the Web modules are loaded by their own separate Web module classloader, and that the application module classloader will not load the web modules for that application. This is the default value. In WebSphere Application Server v4, if we had JAR files that needed to be shared by more than one application, we would place them in the %WAS_ROOT%/lib/app directory. The drawback is that the JARs in the %WAS_ROOT%/lib/app directory are exposed to all the applications. Shared Libraries is a better mechanism, where only applications that need the JARs use them. Other applications are not affected by the shared libraries. The process consists of defining the Shared libraries, naming them and specifying the file or directories that contain Java code and native code. After that, these defined shared libraries can be associated with one or more applications running within the server. The difference between creating Shared libraries this way is that these can be specified for use by just the applications that need them. In comparison, libraries defined when creating Server classloaders are available to all the applications. There is no granularity provided by the server classloader, whereas the shared libraries defined here provide a level of granularity in terms of association with one or more applications as needed. The advantage of using application scoped shared 10

library is the capability of using different versions of common application artifacts by different applications. A unique shared library can be defined for each version of a particular artifact, such as a utility JAR. If a native library loaded by shared library requires a second native library, then it must not be specified in the shared library path, but rather in the JVM native library path and will be loaded by the JVM classloader. When loading of the non-application classes like the JVM classes, WebSphere runtime classes, Resources, and Custom Service class. Custom Service is a pluggable extension of the server runtime that allows you to plug in your own classes Custom Service classes are loaded by the WebSphere Extensions classloader, which is the parent of every Application classloader. Therefore, Custom Services are visible to all applications hosted by an Application Server. Custom Service classes cannot have any dependencies on application classes. When loading of the application related classes. The Stand-alone resource adapters are loaded by the WebSphere extension classloader, whereas the embedded resource adapter is loaded by the Application Module classloader. The Server scoped shared library is loaded by the Server classloader, and therefore is available to all the applications, whereas the shared libraries associated with the application are loaded by the application module classloader, and available only to the application. Native libraries are loaded by Java using the System load library when they are needed. Native libraries could be located in the JVM classloader or one of the WebSphere classloaders such as the Extensions, Server or the Application module classloader. WebSphere Extensions, Server, and Application module classloaders define a local native library path, similar to java.library.path supported by the JVM classloader. When loading a native library, the JVM can throw an exception if the library was already loaded or if the library is not found. Therefore, it is a good practice to load the native library from a static block within the Java code using classloaders that have the life cycle of the server, if you are using WebSphere classloaders to load the native library. The JVM can load multiple definitions of classes by different classloaders. For example, the Xerces parser will be loaded by the WebSphere Extension classloader, and if the application has bundled the Xerces class, the application module classloader could load the local Xerces class. Pre loading classes improves performance during server startup. A preload file is created when the server first starts up. The file contains the name of each class loaded and the JAR file containing the class. The preload file is used for subsequent server startups. New files that might have been loaded during the server startup are added to the preload file. This could occur if a fix pack was applied, which caused addition of new classes. By default, class preloading is enabled. The Dibm.websphere.preload.classes JVM property allows you to disable preloading. If the preload file is deleted, a new one will be generated. Absence of a preload file does not affect the running of the Server. The preload files are saved in the logs directory. There are separate preload files for Application server startup, start server and launch client.. 11

Summary In summary, classloaders, which are a part of the JVM and are responsible for finding and loading class files. And there are no difference Bea or Ibm using Java classloaders. Though be extant BootStrap, Extrnsion and JVM Classpath. Also are similar Bea Application classloading where an application is normally packaged in an Enterprise Archive (EAR) and Everything within an EAR file is considered part of an EAR or can be loaded as standalone applications as JAR, RAR or WAR file and other hand Ibm Application Module Class loader which can load EJB-s, RAR-s, Utility JAR-s and Application Shared libraries. Of course with Bea we can always create custom classloader where all EJB classes are loaded. Bea Weblogic server have User-Defined Classloader for give better control over what is reloadable and provide inter-module class visibility. But there are some restrictions we must point to. If we use a custom classloader hierarchy, servlet reloading is disabled for Web applications in that particular application, the prefer-web-inf-classes flag will be ignored for web applications within that hierarchy, Nesting depth, Module types, Duplicate Entries etc. I must say that I get lots of tips how is right loading a classes, which are different classloders and ways to use them but I also must say I can t produce better or even best company whose product seems be more useful or easy to use. I think it depends needs and experiences. 12

Used literature 1. http://e-docs.bea.com/wls/docs81/index.html 2. http://www-306.ibm.com/software/websphere/ 13