MergingWebappClassLoader for integrating changes at Liferay's core during runtime when developing with Tomcat

• Type: Feature Request
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: 5.2.0
• Fix Version/s: None
• Component/s: Operations, Operations > Performance
• Labels: None
• Environment: Tomcat 5.5.x, ext
• Similar Issues: Show 5 results ; ;

  LPS-5727	Integrate workflow with Liferay core portlets
  LPS-3483	Runtime error of Tomcat deployment to the global class loader
  LPS-34012	Integrate AlloyUI 2.0 with Liferay core
  LPS-14526	Liferay core portlets context changing
  LPS-29917	Resources Importer causing Theme files to be read from tomcat/temp rather than tomcat/webapps

At the Liferay European Symposium I presented the MergingWebappClassLoader as a tool to improved the development process when using Tomcat as development environment. The main idea behind the special class loader is to be able to separate customization or patches of the portal server from the core code by using the ext environment and to integrate the changes into the ROOT web application at runtime. No ant deploy call is needed to make changes available and visible in the browser. This is done by a special class loader that looks for a file first in the ext environment and then in the ROOT application.

The main functionality of the class loader is contained in the files MergingWebappClassLoader.java and MergingFileDirContext.java. Both files have to be loaded by the server class loader. Therefore they should be integrated into the support-tomcat tree. The same is true for the helper class LoaderHelper.java. I put all three files into the attached archive tomcat-server.zip.

Another helper class LoaderHelper.java can be found in the attached archive tomcat-common.zip. This class has to be loader by the common class loader. Therefore the portal-kernal tree would be a good place.

Please note that both helper files use tomcat packages (namely org.apache.catalina.loader and org.apache.naming.resources) to make some package private attributes and methods available. Another solution would be to use reflection instead. In that case, a setAccessible permission would be needed if running with a security manager. On the plus side, both helper classes could be put into packages distinct from Tomcat and there would be no need to put the LoaderHelper into the common loader, because reflection does not check every class loader restriction. In fact, I got some VerifyErrors after moving from reflection to the helper classes. I solved them by putting the helper classes into the correct class loader.

To use the special class loader, the context file of the Root application has to changed. The following example shows the configuration that I am using on my machine. In this example, the liferay-ext document base is merged into the Root document base:

<Context path="" crossContext="true" docBase="${catalina.base}/../../webapps/ROOT/docroot">
  <Loader
    loaderClass="de.hansemerkur.apache.catalina.loader.MergingWebappClassLoader"
    useSystemClassLoaderAsParent="false"
  />
  <Resources
    className="de.hansemerkur.apache.naming.resources.MergingFileDirContext"
    mergingDocBase="${catalina.base}/../../webapps/liferay-ext/docroot"
  />
</Context>

[Vicki Tsang]

Hi Olaf,

Thank you for your contribution. It appears that when the original contribution was made, the Liferay Contributors Agreement was not checked. I have returned this ticket to the reopened state. Please can you verify that the patch will still work with our current release and click on the Contribute Solution button. Once you have accepted the Liferay Contributor's Agreement, please click on Accept Contribution so that our engineering team can identify it for review. Submissions that do not have the Liferay Contributor's Agreement checked cannot be considered for inclusion in the product.

I apologize for any inconvenience this may have caused.

Sincerely, Vicki

[Olaf Fricke]

Hi Vicki,

I have checked that my patch is still working. We are still using it at HanseMerkur with Liferay 5.1 and Liferay 6.0. Nevertheless, the MergingWebappClassLoader does not help much if using hooks instead of an ext environment. Therefore I am currently working on a revised version of the class loader, that will support developers to integrated patches and ext-hooks as well as jsp-hooks.

What do you think would be the best way to contribute this revised version? This Jira ticket with some new attachments or a brand new ticket?

Sincerely,
Olaf

[Randy Zhu]

In preparation for Ideation; we are merging New Feature and Improvement tickets into a singular ticket type called “Feature Request”. Additional information to follow soon.