Java_ a summary of App class loader

Java itself is a very simple design, very sophisticated language, so the principle behind Java is very simple, it boils down to two points:

1, the memory management of the JVM

Understanding this, all problems related to the object can be solved.

2. JVM Class Loader

Understand this, all Java-related configuration issues, including the configuration of a variety of app servers, application publishing issues can all be resolved


APP Class Loader
|-----EJB Class Loader
|-----Web App Class Loader


If configured at the App class loader level, it is globally visible. If packaged in an EJB, it does not affect the Web application and vice versa, and if you place hibernate under Web-inf, it will not affect the EJB. Placed in the EJB class loader or in the Web APP class loader level is mainly in the local scope of the effective, does not affect other applications.

Imagine, if you configure multiple virtual domains on a weblogic, you use www.bruce.com domain name, develop your website, I use www.fankai.com to develop my website, then of course don't want our hibernate to interfere with each other, so we can put in the EJB Class loader level to configure Hibernate.

Further elaboration of the EJB Class loader problem:

Again, hibernate and EJB, and app server do not have compatibility issues, they are irrelevant things, like JDBC, I believe no one would think JDBC and EJB is incompatible, Hibernate is the same, it only and JDBC driver, There are compatibility issues with databases, and EJB, and app server are completely border. Those who think that hibernate and EJB incompatibility, in fact, is because of the EJB learning is not home, the responsibility is pushed to hibernate.

The previous post mentions the class loader hierarchy, which is not repeated here, so let's take a look at the scope of class loader:

BootStrap Class Loader:

Load Jre\lib\rt.jar, Sunrsasign.jar, Charsets.jar, Jce.jar, Jsse.jar, Plugin.jar

Ext Class Loader:

The library file under the load Jre\lib\ext directory, the class under the Load jre\classes directory

APP Class Loader:

Load CLASSPATH variable Specifies the class under the path

The above load path is written dead in the JVM's C + + source code, can not be changed, see Sen Wang's "Java Deep Adventures" in detail

On a particular app server, class loader will continue to inherit downward, and the hierarchy of inheritance will vary depending on the app server, but it will certainly not change:

EJB Class Loader:

Inherited from the app Class Loader, the inheritance hierarchy differs depending on the app server, and an EJB class Loader its load Class is scoped to the jar or ear range.

Web App Class Loader:

Inherited from the app class Loader, the inheritance hierarchy differs depending on the app server, a WEB App class Loader: Its load Class is scoped to the Web-inf\lib library file and web-inf\ The class file under the classes directory.

Web App class loader well understood, after all, a lot of people use, a Web application on app server will create an instance of the Web App Class loader to take charge of the load Class, So if you want hibernate to take effect only in this Web application, put it down to web-inf\lib.

If you put hibernate under the path specified by the CLASSPATH variable and you put a copy in Web-inf\lib, then the web App Class Loader is limited by the load range and will first find web-inf\ Hibernate under Lib, initialize hibernate according to its configuration.

If you put hibernate under the path specified by the CLASSPATH variable, but you don't put anything in the Web-inf\lib, then the web App Class Loader can't find anything because of the load range, so it takes load Hibernate's responsibility is given to the upper class Loader, so that until the app class Loader, it finds Hibernate and initializes hibernate according to its configuration.

The EJB Class Loader is a little more complicated and less easily understood. APP server creates an instance of the EJB Class loader for each EJB package file, for example:

Hellorobbin.jar
Hellobruce.jar

When you publish these two jars to the app server, you will create two instances of EJB Class loader, respectively, to load the two EJB packages, for example:

Clejb_robbin is the load Hellorobbin.jar.
Clejb_bruce is the load Hellobruce.jar.

Then Clejb_robbin's load range is limited to Hellorobbin.jar, it does not load any files outside of Hellorobbin.jar, and of course it does not load to Hellobruce.jar.

Speaking of which, I believe you should understand why the EJB specification does not allow the EJB to have IO operations? Because EJB Class loader can't find any files outside the JAR package!!!

What if you want to implement Hellorobbin.jar and Hellobruce.jar calls to each other now? They use different EJB Class Loader, they can't find each other. The solution is to use the ear.

Now suppose Hellorobbin.jar and Hellobruce.jar both use Hibernate to see how to package and publish:

Helloejb.ear
|------Hellorobbin.jar
|------Hellobruce.jar
|------Hibernate2.jar
|------Pojo.jar (Definition of all persistent objects and jar packages for hbm files)
|------Cglib-asm.jar
|------Commons-beanutils.jar
|------Commons-collections.jar
|------Commons-lang.jar
|------Commons-logging.jar
|------Dom4j.jar
|------Odmg.jar
|------Log4j.jar
|------Jcs.jar
|------hibernate.properties
|------log4j.properties
|------CACHE.CCF
|------Meta-inf\application.xml (The requirements of the Java EE specification, define which EJBS are included in the ear package)

In addition, as required by the EJB specification, Hellorobbin.jar and Hellobruce.jar must also indicate the name of the class library outside the calling jar package, which needs to be defined in the jar package's manifest file:

Hellorobbin.jar
|------meta-inf\manifest. Mf

MANIFEST. The following line must be included in MF:

Class-path:log4j.jar Hibernate2.jar Cglib-asm.jar Commons-beanutils.jar Commons-collections.jar Commons-lang.jar
Commons-logging.jar Dom4j.jar Jcs.jar Odmg.jar Jcs.jar Pojo.jar

This is OK, when the Helloejb.ear is published on the app server, the app server creates an EJB Class loader instance of the EJB in the load ear package, Then, according to the MANIFEST.MF indicated in the EJB jar package, Class-path to find the corresponding class library outside the jar package.

So an ear packet is a bit like a web APPLICATION,EJB Class loader load range, which is within the ear range, it is not load to files outside the ear. Unless hibernate is defined in the path specified by Classpath, in this case, the EJB class Loader cannot find hibernate and can only be handed to the class Loader at the previous level, and finally by the App class Loader find hibernate and initialize it.

Not finished writing, continue to say ...

Since the ear is such a load class rule, suppose Robbin and Bruce both run their own website on the same weblogic, and we don't want the hibernate configuration in our program to be messed up by the other, then we can do this:

Robbin ' s Website:

Robbin.ear
|--------Robbin.war (Package the Web application)
|--------Robbin.jar (developing EJB packaging)
|--------Hibernate2.jar
..........................
|--------meta-inf\application.xml


Bruce ' s Website:

Bruce.ear
|--------Bruce.war (Package the Web application)
|--------Bruce.jar (developing EJB packaging)
|--------Hibernate2.jar
..........................
|--------meta-inf\application.xml

This allows you to run on the same app server without interfering with each other.

Java_ a summary of App class loader