A.3. Class Loading with JBoss JBoss ' class loading scheme is similar to the strategy used by other J2EE application servers, as shown in Figure A-3. Figure A-3. JBoss ClassLoader Hierarchy 
JBoss' ClassLoader hierarchy differs from the strategy used by other J2EE application servers in the following ways:
The ClassLoader Repository The ClassLoader Repository contains all classes loaded by a JBoss instance, including: JBoss' internal boot classes, including its J2EE component implementations Any classes or JARs specified on the command line when starting JBoss All classes or JARs from each deployed application
By default, only one ClassLoader Repository covers the entire server. But you are free to declare any number of repositories and associate any deployed applications with a repository. To keep deployment simple, the JAW Motors application uses the default ClassLoader Repository.
Cross-referencing between EJB JAR and WAR files Within an EAR, an EJB could access classes and/or properties packaged in a WAR file (Log4J for example). The converse is true as wellweb components could access resources bundled in an EJB JAR. However, we do not recommend this practice because it ties you to JBossyour application will not deploy on other application servers.
Loading classes The WAR, EJB JAR, and EAR ClassLoaders do NOT load any classes. When an application loads its classes, each ClassLoader adds its contextual information (classes, property files, and JARs) to the ClassLoader context and defers to its parent. Finally, control passes to the JBoss Application ClassLoader, which loads the class from the ClassLoader Repository.
We still recommend using a Common JAR (that resides in the EAR), which contains all JARs and classes common to both an application's EJB JAR and WAR, because: Some form of packaging JARs in an EAR file works with most J2EE application servers. It enables you to share classes between applications. For example, if EAR 1 and EAR 2 both use com.jbossatwork.util.TextEmail.class, you could factor it out of both applications into a separate deployment. Then you would be free to cycle the EAR files independently and never have to worry about ClassCastExceptions when you hot deploy one of the applications.
|
