Class Loader mechanism for Java, app, EJB, and ear

Java itself is a very simple and sophisticated language, so the principle behind Java is also very simple. It comes down to two points:

1. JVM Memory Management

With this understanding, all object-related problems can be solved.

2. JVM Class Loader

With this understanding, all Java-related configuration problems, including various app server configurations and application release issues, can be solved.

APP Class Loader
| ----- EJB Class Loader
| ----- Web app Class Loader

If it is configured at the app Class Loader level, it is globally visible. If packaged in the EJB, it will not affect the web application, and vice versa, if you put hibernate under the WEB-INF, it will not affect the EJB. Put it on the EJB class loader or on the web app Class Loader level is mainly effective in a local scope, without affecting other applications.

Imagine, if you configure multiple virtual domains on a WebLogic Server, you use www.bruce.com to develop your website, and I use www.fankai.com to develop my website, so of course we do not want our hibernate to interfere with each other, so we can configure hibernate at the EJB Class Loader level.

Further elaborate on the problem of EJB Class Loader:

I would like to emphasize that there is no compatibility problem between Hibernate and EJB and the app server. They are irrelevant, just like JDBC. I believe no one will think that JDBC and EJB are incompatible, the same is true for hibernate, which is only a JDBC driver and has compatibility issues with databases. However, it is totally different from EJB and app server. Anyone who thinks that hibernate and EJB are incompatible is actually failing to learn ejbs and putting their responsibilities on hibernate.

I mentioned the level of Class Loader in my previous post. I will not repeat it here. In short, let's take a look at the scope of the function of Class Loader:

Bootstrap Class Loader:

Load JRE/lib/RT. jar, sunrsasign. jar, charsets. jar, JCE. jar, JSSE. jar, plugin. Jar

EXT Class Loader:

Load the library files under the JRE/lib/EXT directory, and load the classes under the JRE/classes directory

APP Class Loader:

The load classpath variable specifies the class in the path

The above load paths are all written to the C ++ of JVM.Source codeIt cannot be changed. For details, see Wang Sen's Java deep adventure.

On a specific app server, class loader will continue to inherit from each other. The hierarchy of inheritance will vary depending on the app server, but it will certainly not change:

EJB Class Loader:

Inherited from app Class Loader. The Inheritance level varies with app server. The range of an EJB class loader's load class is limited to the jar or ear range.

Web app Class Loader:

Inherited from app Class Loader. The hierarchy varies depending on app server. A web app Class Loader: its Load class scope is the library file under the WEB-INF/lib and the class file under the WEB-INF/classes directory.

The web app class loader is easy to understand. After all, many users use it. A Web application on the app server creates an instance of the web app class loader to load the class, so if you want hibernate to take effect only in this web application, put it in WEB-INF/lib.

If you put hibernate to the path specified by the classpath variable, and you put a copy in the WEB-INF/lib, then the web app class loader is limited by the load range, it will first find the hibernate under the WEB-INF/lib, according to its configuration to initialize hibernate.

If you put hibernate to the path specified by the classpath variable, but you didn't put anything in the WEB-INF/lib, then the web app class loader is limited by the load range, it couldn't find anything at all, so it handed over the load hibernate responsibility to the class loader at the upper level until the app Class Loader found Hibernate and initialized hibernate according to its configuration.

EJB class loader is a little complicated and not easy to understand. APP server creates an EJB Class Loader instance for each EJB package file, for example:

Hellorobbin. Jar
Hellobruce. Jar

After you publish these two jars to the app server, two EJB Class Loader instances will be created to load the two EJB packages respectively, for example:

Clejb_robbin is from load hellorobbin. jar.
Clejb_bruce is from load hellobruce. jar.

Therefore, the load range of clejb_robbin is limited to hellorobbin. Jar. It cannot load any files other than hellorobbin. jar, and of course it cannot load hellobruce. jar.

Speaking of this, I believe everyone should have understood why the EJB specification does not allow I/O operations on ejbs? Because the file other than the jar package cannot be found in EJB Class Loader !!!

What if you want to implement mutual calls between hellorobbin. jar and hellobruce. jar? They use different EJB class loaders and cannot find each other. The solution is to use ear.

Now let's assume that both hellorobbin. jar and hellobruce. Jar use Hibernate and see how to package and release it:

Helloejb. Ear
| ------ Hellorobbin. Jar
| ------ Hellobruce. Jar
| ------ Hibernate2.jar
| ------ Pojo. Jar (defines all persistent objects and jar packages of 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 (J2EE specification requirements, defining which ejbs are included in the ear package)

In addition, according to the EJB specification, hellorobbin. jar and hellobruce. jar must also specify the name of the Class Library outside the jar package, which needs to be defined in the manifest file of the jar package:

Hellorobbin. Jar
| ------ META-INF/manifest. MF

Manifest. MF must include the following line:

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

In this case, it's okay. after the ear is published to the app server, the app server creates an EJB Class Loader instance to load the EJB in the ear package, and then according to the manifest in the jar package of the EJB. mf points out the class-path to find the class libraries outside the corresponding jar package.

Therefore, an ear package is similar to a web application. The load range of the EJB class loader is within the ear range, and it cannot load files other than 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 over to the class loader at the upper level. Finally, the app class loader finds hibernate,.

Not finished. Continue...

Because of the class load rules such as ear, assuming that both Robbin and Bruce are running their own websites on the same WebLogic, we do not want their ownProgramThe Hibernate configuration in it is messed up by the other party, so we can do this:

Robbin's website:

Robbin. Ear
| -------- Robbin. War (package the Web Application)
| -------- Robbin. Jar (package the developed EJB)
| -------- Hibernate2.jar
..........................
| -------- META-INF/application. xml

Bruce's website:

Bruce. Ear
| -------- Bruce. War (package the Web Application)
| -------- Bruce. Jar (package the developed EJB)
| -------- Hibernate2.jar
..........................
| -------- META-INF/application. xml

In this way, you can run on the same app server without interfering with each other.