Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool
Similar a WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool (20)
WebLogic's ClassLoaders, Filtering ClassLoader and ClassLoader Analysis Tool
- 1. WebLogic Server 11gR1 PS3 (10.3.4) DEMOFiltering ClassLoader & Classloader Analysis Tool Jeffrey West Application Grid Product Management
- 2. Agenda Overview of WebLogic’s ClassLoaders Overview of WebLogic’s ClassLoader Analysis Tool Demo of WebLogic’s ClassLoader Analysis Tool Conclusion & WebLogic Resources
- 4. Classes on the System Classpath
- 6. Any Modules defined in the application
- 7. Libraries from Java EE 5 <library-directory> directive or /lib if none configured
- 10. WEB-INF/lib
- 11. Enables Servlets and JSPs to see EJB classes
- 12. Enables redeployment of Web Apps w/o redeploying EJBsWEB APP
- 13. 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
- 14. 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
- 15. 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
- 16. 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
- 17. Agenda Overview of WebLogic’s ClassLoaders Overview of WebLogic’s ClassLoader Analysis Tool Demo of WebLogic’s ClassLoader Analysis Tool Conclusion & WebLogic Resources
- 18. 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
- 20. Agenda Overview of WebLogic’s ClassLoaders Overview of WebLogic’s ClassLoader Analysis Tool Demo of WebLogic’s ClassLoader Analysis Tool Conclusion & WebLogic Resources
- 21. Agenda Overview of WebLogic’s ClassLoaders Overview of WebLogic’s ClassLoader Analysis Tool Demo of WebLogic’s ClassLoader Analysis Tool Conclusion & WebLogic Resources
- 22. 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
Notas del editor
- Thereare several levels of classloaders used in WebLogic. <CLICK>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.<CLICK>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.<CLICK>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.<CLICK> 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. <CLICK> As of WebLogic 10.3.3 the WebLogic.XML descriptor supports the same prefer-application-packages XML element as the weblogic-application.xml descriptor. <CLICK> 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.