Wednesday, March 04, 2009

A Portlet Class Loading Scheme

According JVM Spec 5.3 Creation and Loading, there are two situations for a class D to load or to initiate loading another class C: either there are references to C in D's constant pool, or D creates C using reflection. In either case, if D was defined by a user-defined class loader, then that same user-defined class loader initiates loading of C.

Let's assume the portal framework is a web application, and it has the following directory structure:
WEB-INF/
classes/
lib/
portlets/
portlet1/
classes/
lib/
portlet2/
classes/
lib/
The web application class loader W will create a portlet class loader P for each portlet, that has W as its parent class loader and is responsible to load classes from portletx/classes and portletx/lib. W will use P to instantiate a portlet entry point using reflection. From the portlet entry point, all required classes will be then loaded by P, but still following the delegation model. It means W will try to load class first, only after that fails, P will load.

This scheme does not violate Servlet Spec 2.4, which states "The Web application class loader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory. Also, any requests from the client to access the resources in WEB-INF/ directory must be returned with a SC_NOT_FOUND(404) response." It does not prevent loading class from elsewhere.

The advantages of such a scheme are:
  1. It takes the view that the portal framework is a web application; its portlets are just its components instead of web applications themselves.
  2. It respects the class loading scheme of the web application server. The portal framework jars can be kept inside the web application, and the portlets share those jars naturally.
  3. It also facilitates deploying and undeploying portlets on the fly, because the control is purely inside the portal web application.

No comments: