Java itself is a very simple, very checkered language, so the principles behind Java are also very simple. It is two points: 1. JVM memory management understands this, all and object-related issues can be all possible Solve 2, JVM Class Loader understands this, all and Java-related configuration issues, including various App Server configuration, application issuance issues can solve App Class Loader | ----- EJB Class Loader | --- Web App Class Loader If the App Class Loader level configuration is globally visible. If you pack it in EJB, then you will not affect the Web Application, and vice versa, if you place hibernate under Web-INF, you will not affect EJB. Putting in EJB Class Loader or placed in the Web App Class Loader is mainly valid within the local area without affecting other applications. Imagine if you configure multiple virtual domains on a WebLogic, you use www.bruce.com domain names, develop your website, I use www.fankai.com to develop my website, then I don't want our hibernate to interfere with each other, so You can configure Hibernate at the EJB Class Loader level. Further explanation of EJB Class Loader: First emphasize, Hibernate and EJB, and App Server does not have compatibility issues, they are not related, just like JDBC, I believe that no one will think that JDBC and EJB are not compatible. Hibernate is also the same, it is only with the JDBC driver, and the database is compatible with the database, and the EJB, and the App Server are completely unwinding. Anyone who believes that Hibernate and EJB is not compatible, is actually because of the unhappy family of EJB, pushing responsibility to hibernate. My previous post refers to the level of Class Loader, here is not repeated, in short, let's take a look at the scope of Class Loader: Bootstrap Class Loader: loading jre / lib / rt.jar, Sunrsign.jar, chars.jar, JCE.jar, jsse.jar, plugin.jar ext class loader: Load jre / lib / ext directory, LOAD JRE / CLASSES directory class App Class Loader: load classpath variable Specify the path under the path to the above Load The path is written in the C source code in the JVM. It cannot be changed. Please see Wang Sen's "Java Depth Adventures" on a specific App Server, Class Loader will continue to inherit down, the inherited level will depend App Server is different, but it is definitely not changed: EJB Class Loader: Inherits from App Class Loader, inherited levels different from App Server, an EJB Class Loader has the range of Load Class is only in JAR or EAR range within.
Web App Class Loader: Inherited from App Class Loader, inherited hierarchical different from App Server, a web app class loader: its LOAD Class's library file and web-inf / class directory under web-inf / lib Class file. Web App Class Loader is very understanding, everyone is using a lot, a web application on the app server will create an instance of a web app class loader to be responsible for the Load Class, so if you want Hibernate to take effect only within this web application, It is fine to put it on Web-INF / LIB. If you put Hibernate under the path specified by the classpath variable, you also put a copy in web-inf / lib, then the web app class loader is limited by the LOAD range, which will first find the Web-INF / LIB. Hibernate, initialize Hibernate according to its configuration. If you put Hibernate under the path specified by the classpath variable, you have not put anything in web-inf / lib, then the web app class loader is not found because of the limit of the LOAD, so it will take load hibernate. The responsibility is handed over to the previous level of Class Loader so until App Class Loader, it finds Hibernate, and initializes Hibernate according to its configuration. EJB Class Loader is slightly complicated, not so easy to understand. App Server creates an instance of EJB Class Loader for each EJB package file, for example: hellorobbin.jar Hellobruce.jar When you release these two JARs on the App Server, you will create an instance of two EJB Class Loader, respectively. Go to LOAD these two EJB packages, such as: Clejb_robbin is the CLEJB_BRUCE of Load hellorobbin.jar is the LOAD Hellobruce.jar of Clejb_Robbin's LOAD range only within Hellobbin.jar, it does not reach HelloBbin.jar anything other than Hellobbin.jar Document, of course, it is also LOAD not to hellobruce.jar. Speaking here, I believe that everyone should have understood why the EJB specification does not allow EJBs to have IO operations? Because EJB Class Loader can't find files outside the JAR package at all! ! ! If you want to achieve Hellorobbin.jar and Hellobruce.jar, what should I do? They use different EJB Class Loader, which cannot be found to each other. The solution is to use EAR.
Now, Hellorobbin.jar and Hellobruce.jar use Hibernate to see how to pack and release: Helloejb.ear | ------ Hellobbin.jar | ------ Hellobruce.jar | ---- - hibernate2.jar | ------ Pojo.jar (define all persistent objects and HBM file JAR package) | ------ 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, define which EJB in the EAR package) In addition to the EJB specification, Hellorobbin .jar and hellobruce.j must also point out the name of the class library other than the JAR package, which requires a manifest file in the JAR package: Hellobbin.jar | ------META-INF / Manifest.mf manifest. MF must include the following rows: Class-path: log4j.jar hibernate2.jar cglib-asm.jar commiss-beanutils.jar Commons-Collections.jar Commons-lang.jar Commons-logging.jar Dom4j.jar jcs.jar ODMG. JAR JCS.jar pojo.jar This is OK, after the Helloejb.ear is released on the App Server, App Server creates an EJB Class Loader instance load eleb, and then according to the manifest.mf in the jar package of EJB Class-path pointed out to find a class library other than the corresponding JAR package. So an EAR is a bit similar to a web application. The LOAD range of EJB Class Loader is also within the EAR range, which is not files outside EAR. Unless the Hibernate is defined to the path specified by the classpath, in this case, the EJB Class Loader can't find Hibernate, which can only be handed over to the Class Loader of the previous level, and finally find hibernate by app class loader for initialization.
