WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool
Upcoming SlideShare
Loading in...5
×
 

WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool

on

  • 10,701 views

 

Statistics

Views

Total Views
10,701
Views on SlideShare
8,620
Embed Views
2,081

Actions

Likes
2
Downloads
99
Comments
0

19 Embeds 2,081

http://www-ig-opensocial.googleusercontent.com 726
http://www.iamjambay.com 382
http://orablogs-jp.blogspot.jp 358
http://blogs.oracle.com 301
http://orablogs-jp.blogspot.com 143
http://lizintexas.wordpress.com 79
http://feeds.feedburner.com 51
url_unknown 14
http://webcache.googleusercontent.com 7
http://www.javaoracleblog.com 5
http://orablogs-jp.blogspot.in 5
http://orablogs-jp.blogspot.ro 2
http://orablogs-jp.blogspot.com.es 2
http://www.google.com HTTP 1
http://orablogs-jp.blogspot.fr 1
http://translate.googleusercontent.com 1
http://orablogs-jp.blogspot.co.nz 1
http://orablogs-jp.blogspot.ru 1
http://orablogs-jp.blogspot.nl 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Thereare several levels of classloaders used in WebLogic. Obviously, there is the top-level classloader that loads the WebLogic implementation classes and supporting libraries defined on the classpath, including those added to setDomanEnv and commEnv. This is called the SYSTEM classloader.The next level of classloader is at the domain level. This classloader is a child to the SYSTEM classloader and loads libraries that are included in the domain – slash – lib directory.Generally speaking, WebLogic Server classloading is centered on the concept of domains and applications. 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. If you deploy an EJB and a Web application separately, they are considered two applications. WebLogic Server automatically creates a hierarchy of classloaders when an application is deployed. The root classloader in this hierarchy is the APPLICATION classloader and it loads modules defined in the application, including EJBs, as well as java EE shared libraries and libraries included in the configured library directories for the application. A child classloader is created for each Web application WAR file and loads the shared Java EE libraries as well as the libraries and compiled classes in the WEB-INF folder.So, why did we do this? It is common for Web applications to call EJBs, and the WebLogic Server application classloader architecture allows JSPs and servlets to see the EJB interfaces in their parent classloader. This allows for EJB’s to be called by reference for higher performance.This architecture also allows Web applications to be redeployed without redeploying the EJB tier. If you deploy the WAR and JAR files separately, WebLogic Server creates sibling ClassLoaders for them. This means you have to do some additional work to have your JSPs and servlets hit your EJBs. However, this changes a bit with EE6 since you can package EJB’s in WAR files, which will be a much needed feature that I am looking forward to.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.
  • WebLogic offers a feature called the Filtering ClassLoader which overrides the TOP-DOWN classloading and essentially enables child-first classloading. When filtering is enabled, the resources from the child of the FilteringClassLoader (an application classloader) down to the calling classloader are returned before the ones from the system classloaderWhat this allows you to do is specify a set of Java packages that should always be loaded from the APPLICATION, not the SYSTEM classloader. The SYSTEM classloader loads the libraries that are included with WebLogic, so if you want to override the version of a library and include it in your WAR or EAR file you can use the Filtering ClassLoader to do that. Some common examples of this are ANTLR, XERCES and other XML tools that already have versions included in WebLogic. It is also possible to use this in order to use a newer version of JAX-WS than is included in WebLogic.
  • Lets take a look at how you would configure the filtering classloader. To configure a FilteringClassLoader for an application you must explicitlyspecify the packages that should be loaded by the APPLICATION-levelclassloaders. These can be from the library folders or they can be shared Java EE libraries that you may be are using. This is done in the weblogic-application.xml file when deploying an EAR file or in the weblogic.xml file when deploying a WAR file.You can see an example of this at the bottom of the slide here. This example is configuring the Filtering ClassLoader to load LOG4J and ANTLR packages from the application-level classloaders, not the SYSTEM classloaders.
  • The Filtering ClassLoader is also available for Web Applications. As of WebLogic 10.3.3 the WebLogic.XML descriptor supports the same prefer-application-packages XML element as the weblogic-application.xml descriptor. Before version 10.3.3 we supported a configuration for prefer-web-inf-classes but this did not account for libraries packaged in a WAR file.In an act of desperation in the past, I once unzipped all the jar files I wanted to use in a WAR file and put all the classes in the WEB-INF/classes directory and enabled prefer-web-inf-classes in order for WebLogic to use the classes that I wanted. This is obviously less than optimal and somewhat of a hack. The Filtering ClassLoader for Web Applications allows you to use the jars that you want without having to do something like this.
  • You can also 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. User-defined classloader restrictions give you better control over what is reloadable and provide inter-module class visibility.This feature is primarily for developers and it is useful for iterative development. However, 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 elementsThe 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 gives you a lot of options around configuring a classloader hierarchy if you want to do so, but its not required in order to be successful with WebLogic.
  • TO go into a bit more detail, the ClassLoader Analysis tool allows you to analyse conflicts to see the different versions of a class that are being loaded with the current classloader configuration. By analyzing the class conflicts you can determine how you want to configure the Filtering ClassLoader. Some ‘conflicts’ are not an issue. For example, if your application wants to use version 1.4.5 of a library and the version included with WebLogic is 1.4.6 then the ‘conflict’ may not have any side-effects. For example, the CAT identifies several conflicts when Hudson is deployed, but Hudson works perfectly fine without configuring the filtering classloader.The purpose of the ClassLoader Analysis Tool is to provide you with the information you need to decide how you want to configure the classloader in order to solve classloading problems.
  • The ClassLoader Analysis Tool will provide you with a list of packages, and the corresponding XML for configuring the Filtering ClassLoader. You can take the XML, confirm that the packages are the ones you want to filter and then put the XML in the deployment descriptor in order to configure the Filtering ClassLoader. When you redeploy the application with the new deployment descriptor you can look at the ClassLoader Analysis tool output again and see what the result of the configuration that was just applied.Without this tool, identifying the classes that are causing a conflict, then pulling out the package names, and finally configuring the deployment descriptors can be a very painful process. This new tool greatly reduces the effort to perform the analysis and configure the deployment descriptors, which in turns makes it easier and faster to deploy open source software that packages many third party libraries.
  • You can find more information about WebLogic online on the Oracle Technology Network, YouTube, Twitter and Facebook.

WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool Presentation Transcript

  • WebLogic Server 11gR1 PS3 (10.3.4) DEMOFiltering ClassLoader & Classloader Analysis Tool
    Jeffrey West
    Application Grid Product Management
  • Agenda
    Overview of WebLogic’s ClassLoaders
    Overview of WebLogic’s ClassLoader Analysis Tool
    Demo of WebLogic’s ClassLoader Analysis Tool
    Conclusion & WebLogic Resources
  • WebLogic ClassLoader HierarchyTop-Down Class Loading (Default)
    SYSTEM ClassLoader loads:
    • WebLogic Implementation classes
    • Classes on the System Classpath
    • PRE_CLASSPATH and EXT_PRE_CLASSPATH
    SYSTEM
    DOMAIN ClassLoader loads:
    • Classes from <domain_dir>/lib
    DOMAIN
    APPLICATION ClassLoader loads:
    • Java EE Shared Libraries referenced in weblogic-application.xml
    • Any Modules defined in the application
    • Libraries from Java EE 5 <library-directory> directive or /lib if none configured
    • Libraries from <EAR>/APP-INF/lib
    APPLICATION
    WEB APP ClassLoader loads:
    • Java EE Shared Libraries referenced in weblogic.xml
    • WEB-INF/classes
    • WEB-INF/lib
    • Enables Servlets and JSPs to see EJB classes
    • Enables redeployment of Web Apps w/o redeploying EJBs
    WEB APP
  • APPLICATION
    WEB APP
    WebLogic Filtering ClassLoaderForce classes to be loaded from the APPLICATION
    The FilteringClassLoader mechanism allows you to specify classes that should always be loaded from the application (not the SYSTEM ClassLoader)
    This allows you to use alternate versions of applications, such as Xerces and Ant, than those that are packed with WebLogic
    Enables resources from the child of the FilteringClassLoader (an Application classloader) down to the calling classloader are returned before the ones from the system classloader
    The FilteringClassLoader is configured with a list of packages specified in weblogic-application.xml or weblogic.xml (introduced in 10.3.3) files.
    SYSTEM
    DOMAIN
    FILTERING
    ClassLoader
  • Filtering ClassLoader ConfigurationSpecify Packages to load from APP-INF/lib & WEB-INF/lib
    Specify the packages that should be loaded by the Application including:
    Java EE Shared Libraries
    EAR: /lib (preferred)
    EAR: APP-INF/lib
    WAR: WEB-INF/lib
    Overrides the classes that are loaded with WebLogic allowing you to use libraries that may conflict with those included in WebLogic
  • There are two options for configuring the classloader in at the Web Application level
    <container-descriptor> / <prefer-application-packages>
    <container-descriptor> / <prefer-web-inf-classes>
    Only one of these options can be used at a time
    Oracle recommends using <prefer-application-packages> to configure the FilteringClassLoader
    <prefer-application-packages>
    (Recommended)
    <prefer-web-inf-classes>
    Allows a Web Application to use its own third-party libraries from WEB-INF/lib by specifying certain packages that should always be loaded from the Web Application
    Allows a Web application to use its own version third-party classes from WEB-INF/classes, which might also be part of WebLogic Server
    Web Filtering ClassLoader ConfigurationLoad Classes from WEB-INF
  • Customer ClassLoader StructureAdvanced Configuration for Reloading Classes
    Custom classloader hierarchies allow better control over class visibility and reload-ability
    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
  • Agenda
    Overview of WebLogic’s ClassLoaders
    Overview of WebLogic’s ClassLoader Analysis Tool
    Demo of WebLogic’s ClassLoader Analysis Tool
    Conclusion & WebLogic Resources
  • WebLogic ClassLoader Analysis ToolNEW in WebLogic 11gR1 (10.3.4)
    Application provided libraries can collide with 3rd party libraries used by WebLogic Server
    Hard to diagnose class and library conflicts
    Filtering Classloader feature enables applications to use their own libraries
    Correctly configuring it can be a challenge
    Classloader Analysis Tool Helps Identify and Resolve Conflicts Quickly
    CAT cracks open the classloader black box
    Displays classloaders’ hierarchies and sources
    Allows you to search for a class/resource on a classloader
    Views class definitions, interfaces
    Analyzes classpath conflicts, generates corresponding filtering classloader configuration
    CAT
    WebLogic
    ClassLoaders
  • Analyze Classpath ConflictsWebLogic 10.3.4 ClassLoader Analysis Tool
    The ClassLoader Analysis tool shows you where the class conflicts are
    • This allows you to see the conflicting libraries, where they are located and allows you to decide how to resolve it
  • ClassLoader Configuration SuggestionWebLogic 10.3.4 ClassLoader Analysis Tool
    The ClassLoader Analysis tool provides the XML configuration necessary for configuring the Filtering ClassLoader
    This significantly eases the configuration required to take advantage of this advanced feature
    Only available in WebLogic 10.3.4 and later
  • Agenda
    Overview of WebLogic’s ClassLoaders
    Overview of WebLogic’s ClassLoader Analysis Tool
    Demo of WebLogic’s ClassLoader Analysis Tool
    Conclusion & WebLogic Resources
  • Agenda
    Overview of WebLogic’s ClassLoaders
    Overview of WebLogic’s ClassLoader Analysis Tool
    Demo of WebLogic’s ClassLoader Analysis Tool
    Conclusion & WebLogic Resources
  • Find us Online!
    www.YouTube.com/OracleWebLogic
    Give us feedback! @OracleWebLogic
    www.twitter.com/OracleWebLogic
    www.facebook.com/OracleWebLogic
    www.oracle.com/technetwork/middleware/weblogic