Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-7

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

    Details

    • Type: Feature Request
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: 5.2.0
    • Fix Version/s: None
    • Component/s: Performance
    • Labels:
      None
    • Environment:
      Tomcat 5.5.x, ext

      Description

      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>
      

        Attachments

          Activity

            People

            • Assignee:
              support-lep@liferay.com SE Support
              Reporter:
              frickeo Olaf Fricke
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 1 week, 1 day
                1w 1d
                Remaining:
                Remaining Estimate - 1 week, 1 day
                1w 1d
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Subcomponents