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 Feature Request
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 5.2.0
    • Fix Version/s: None
    • Component/s: Performance
    • Labels:
      None
    • Environment:
      Tomcat 5.5.x, ext
    • Similar Issues:
      Show 5 results 

      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>
      

        Activity

        Hide
        Vicki Tsang added a comment -

        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

        Show
        Vicki Tsang added a comment - 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
        Hide
        Olaf Fricke added a comment -

        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

        Show
        Olaf Fricke added a comment - 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
        Hide
        Randy Zhu added a comment -

        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.

        Show
        Randy Zhu added a comment - 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.

          People

          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Days since last comment:
              2 years, 20 weeks, 2 days ago

              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

                Development

                  Structure Helper Panel