gembin
          

          OSGi, Eclipse Equinox, ECF, Virgo, Gemini,  Apache Felix, Karaf, Aires, Camel, Eclipse RCP

          
HBase, Hadoop, ZooKeeper, Cassandra

          

Flex4, AS3, Swiz framework, GraniteDS, BlazeDS etc.

          

There is nothing that software can't fix. Unfortunately, there is also nothing that software can't completely fuck up. That gap is called talent.


          

About Me




          

           
          
			
          
				
					
	
          
		
          
			WebLogic's Classloading Framework
		
          
		Running any application on a JVM or an application server (e.g., WebLogic Server), the main question a designer faces is:
          • Which class is getting loaded from which source
          A classloader is used by the JVM to locate and load Java classes into memory at runtime. Java classloaders define a hierarchy, a tree-like collection of parent and child classloaders.

          Classloader Hierarchy and Visibility
          Classloader hierarchy plays an important role when locating and loading classes into memory. There are two important points to remember:
          1. Classloaders follow the delegation model when loading classes (i.e., current classloader asks its parent for the class if a class is not found in the cache).
          2. A child classloader loads a class only if its parent fails to load it (i.e., even if both parent and child classloaders have access to a particular class, and the child classloader receives a request to load the class, it is the parent that actually loads the class).
            • See customization section for an exception that is supported by WebLogic Server to override this default behavior by setting the prefer-web-inf-classes element to true in the weblogic.xmldescriptor file.
          The application that triggered the request to load a class receives a ClassNotFoundException if neither the classloader nor any of its ancestors can locate the class.

          The visibility of a class definition is determined by the following rules:
          • Any classes loaded by a classloader are visible directly or indirectly, to all its descendants.
          • A parent classloader cannot see any class loaded by any of its child classloaders
          • A classloader cannot access any classes loaded by a sibling classloader.
          Java Classloader Hierarchy
          The bootstrap classloader is the root of the Java classloader hierarchy. The details of Java classloader hierarchy is described below:
          1. Bootstrap classloader (root)
            • Created by the JVM for loading its internal classes and the java.* packages (i.e., core Java libraries under /lib directory) included within the JVM
            • Written in native code
          2. Extensions classloader (child of bootstrap classloader)
            • Loads any JARs placed in the extensions directory (/lib/ext or any other directory specified by thejava.ext.dirs system property) of the JDK
            • Implemented by the sun.misc.Launcher$ExtClassLoader class
          3. System classloader (child of extensions classloader)
            • Loads code found on java.class.path, which maps to the system CLASSPATH variable.
            • Implemented by the sun.misc.Launcher$AppClassLoader class
            • Any custom classloader created by an application, including WebLogic's classloaders, are all descendants of this system classpath classloader.
          WebLogic's Classloading Framework
          WebLogic's standard classloading framework needs to achieve two main goals:
          1. Maintain application independence
            • Classes used by application A must never come in conflict with any classes used by application B
            • Redeploying application A must have no effect on classes used by application B
          2. Hot-deploy or hot-redeploy
            • Within an application, it must allow you to redeploy web applications without having to redeploy the EJBs
            • It is more common to change JSP files and servlets than to change the EJB tier. With proper design, a separate classloader can be created for each servlet and JSP page. This allows you to reload individual servlets and JSPs easily, without the need for redeploying the web application or affecting any of the EJBs.

          WebLogic achieves the first goals by creating a separate classloader hierarchy for each application deployed to the server. The parent of this hierarchy is the system classpath classloader. By creating a separate classloaderhierarchy for each application, classloaders associated with one application cannot see the classloaders or classes of another application, and because sibling classloaders are isolated from each other, this also isolates the applications.

          Java classloaders do not have any standard mechanism to undeploy or unload a set of classes, nor can they load new versions of classes. To achieve the second goal, each application in WebLogic Server has a hierarchy of classloaders (see the Figure below) 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. To find out more details on this, read WebLogic Server Application Classloading.

          Customization
          Even with good support from either Java classloading framework or WebLogic's application classloading framework, it often comes times that you need to have better control over which modules are reloadable, which classes are visible between modules, etc.

          There are multiple solutions to your customization needs:
          1. You can configure a web application classloader so that it doesn't use the default parent delegation scheme by setting the prefer-web-inf-classes element to true in the weblogic.xml descriptor file. See details here.
          2. The FilteringClassLoader provides a mechanism for you to configure deployment descriptors to explicitly specify that certain packages should always be loaded from the application, rather than being loaded by the system classloader. See details here.
          3. 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. See details here.
          Wrap-up
          More often than not, you want class definitions (which are stable) shared across applications. To facilitate sharing, you would place them at higher level of the classloading hierarchy (for example, getting loaded at system classloader instead of at application classloader).

          If it is common to change some modules, a separate classloader can be created for them and place them at the tip of the classloading tree. This allows you to reload individual modules easily, without the need for redeploying their parent applications.
          References
          1. Classloader
          2. JRebel
          3. Understanding WebLogic Server Application Classloading
          4. WebLogic: The Definitive Guide
          5. WebLogic Server 11g for ADF/Forms Developers
          
		
          
			posted on 2011-08-16 16:49 gembin 閱讀(592) 評論(0)  編輯  收藏  所屬分類: JavaEE 、Oracle 
		
          
	
          
	
	


	


          
	    
    




          








          

				
			
          
			
          
				
					

          導航
          

					

          統計
          
	
					
					

          常用鏈接
          


          留言簿(6)
          


		
          隨筆分類(440)
          
		
				
			
	
		
          隨筆檔案(378)
          
		
				
			
	
		
          文章檔案(6)
          
		
				
			
	
		
          新聞檔案(1)
          
		
				
			
	
		
          相冊
          
		
				
			
	
		
          收藏夾(9)
          
		
				
			
	
		
          Adobe
          
		
				
			
	
		
          Android
          
		
				
			
	
		
          AS3
          
		
				
			
	
		
          Blog-Links
          
		
				
			
	
		
          Build
          
		
				
			
	
		
          Design Pattern
          
		
				
			
	
		
          Eclipse
          
		
				
			
	
		
          Favorite Links
          
		
				
			
	
		
          Flickr
          
		
				
			
	
		
          Game Dev
          
		
				
			
	
		
          HBase
          
		
				
			
	
		
          Identity Management 
          
		
				
			
	
		
          IT resources
          
		
				
			
	
		
          JEE
          
		
				
			
	
		
          Language
          
		
				
			
	
		
          OpenID
          
		
				
			
	
		
          OSGi
          
		
				
			
	
		
          SOA
          
		
				
			
	
		
          Version Control
          
		
				
			
	


          最新隨筆
          

          


          



          搜索
          



          積分與排名
          



          最新評論
	
          

          
	
			
		

          


          閱讀排行榜
          

          
	
			
		

          


          評論排行榜
          

          
	
			
		

          

				
			
          			
			

	

          



free counters



    







          
        
	




主站蜘蛛池模板：
中西区|
潼关县|
海口市|
栾城县|
和平区|
萨嘎县|
万宁市|
冷水江市|
德兴市|
措美县|
内丘县|
黄山市|
望江县|
永定县|
漠河县|
丰镇市|
凌源市|
涿鹿县|
海原县|
昭平县|
徐汇区|
奇台县|
远安县|
钟祥市|
阳泉市|
且末县|
临邑县|
襄樊市|
久治县|
永兴县|
元江|
开原市|
临邑县|
天水市|
凤凰县|
墨竹工卡县|
杨浦区|
江永县|
盐源县|
贵州省|
博白县|