All Liferay DXP applications live in its OSGi container. Portal is a web application deployed on your application server. Portal’s Module Framework bundles (modules) live in the OSGi container and have classloaders. All the classloaders from Java’s Bootstrap classloader to classloaders for bundle classes and JSPs are part of a hierarchy.
This tutorial explains Liferay’s classloader hierarchy and describes how it works in the following contexts:
- Web application, such as Liferay Portal, deployed on the app server
- OSGi bundle deployed in the Module Framework
The following diagram shows Liferay’s classloader hierarchy.
Here are the classloader descriptions:
Bootstrap: The JRE’s classes (from packages
java.*) and Java extension classes (from
$JAVA_HOME/lib/ext). No matter the context, loading all
java.*classes is delegated to the Bootstrap classloader.
System: Classes configured on the
CLASSPATHand or passed in via the application server’s Java classpath (
Common: Classes accessible globally to web applications on the application server.
Web Application: Classes in the application’s
Module Framework: Liferay’s OSGi module framework classloader which is used to provide controlled isolation for the module framework bundles.
bundle: Classes from a bundle’s packages or from packages other bundles export.
JSP: A classloader that aggregates the following bundle and classloaders:
- Bundle that contains the JSPs’ classloader
- JSP servlet bundle’s classloader
- Javax Expression Language (EL) implementation bundle’s classloader
- Javax JSTL implementation bundle’s classloader
Service Builder: Service Builder classes
The classloader used depends on context. Classloading rules vary between
application servers. Classloading in web applications and OSGi bundles differs
too. In all contexts, however, the Bootstrap classloader loads classes from
Classloading from a web application perspective is up next.
Application servers dictate where and in what order web applications, such as Liferay DXP, search for classes and resources. Application servers such as Apache Tomcat enforce the following default search order:
- Bootstrap classes
- Web app’s
- web app’s
- System classloader
- Common classloader
First, the web application searches Bootstrap. If the class/resource isn’t there, the web application searches its own classes and JARs. If the class/resource still isn’t found, it checks the System classloader and then Common classloader. Except for the web application checking its own classes and JARs, it searches the hierarchy in parent-first order.
Application servers such as Oracle WebLogic and IBM WebSphere have additional classloaders. They may also have a different classloader hierarchy and search order. Consult your application server’s documentation for classloading details.
The Bundle Classloading Flow tutorial explains classloading from an OSGi bundle perspective.
Classloading for JSPs and Service Builder classes is similar to that of web applications and OSGi bundle classes.
You now know Liferay DXP’s classloading hierarchy, understand it in context of web applications, and have references to information on other classloading perspectives.