Let's assume the portal framework is a web application, and it has the following directory structure:
WEB-INF/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.
classes/
lib/
portlets/
portlet1/
classes/
lib/
portlet2/
classes/
lib/
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:
- It takes the view that the portal framework is a web application; its portlets are just its components instead of web applications themselves.
- 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.
- It also facilitates deploying and undeploying portlets on the fly, because the control is purely inside the portal web application.
No comments:
Post a Comment