PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-21241

tomcat7 fails to reload jsp that has been updated by server-manager-web delta update mechanism

    Details

    • Similar Issues:
      Show 5 results 

      Description

      When a portlet plugin is deployed by Liferay IDE using the new server-manager-web API, it deploys the war to the remote server and deploys normally. However, when Liferay IDE deploys a delta-war update to just change one deployed file (view.jsp), the new view.jsp file is correctly updated in the webapps folder of the remote tomcat via the server-manager-web API however, tomcat does not reload the JSP.

        Activity

        Hide
        Gregory Amerson added a comment -

        During the portlet deploy process it will copy a META-INF/context.xml file that has the following contents:

        <Context
        antiJARLocking="true"
        antiResourceLocking="true"
        />

        This causes tomcat7 to create a complete copy of all the times to the temp/ folder and open those files instead of the ones residing in webapps.

        The problem comes when the developer makes a change to a single file (view.jsp), and then pushes that update to the server via the sever-manager-web API. The server-manager-web will update the single file in the webapps/<context> deployed location. However this will not affect tomcat's jsp reloading logic since it is looking at the JSP that is in the temp directory due to the antiResouceLocking=true setting.

        What is interesting is that tomcat6 the context.xml file with the antiResourceLocking=true setting was still being set but tomcat6 doesn't seem to honor that setting. however, tomcat7 does now pay attention.

        This is going to break one of the key features of Remote development for plugins, being able to update just a single jsp/java/resource file in a portlet and avoid having to re-deploy the entire application which involves uploading potentially large war files and waiting for the redeploy/ reloading of context on server's side.

        Show
        Gregory Amerson added a comment - During the portlet deploy process it will copy a META-INF/context.xml file that has the following contents: <Context antiJARLocking="true" antiResourceLocking="true" /> This causes tomcat7 to create a complete copy of all the times to the temp/ folder and open those files instead of the ones residing in webapps. The problem comes when the developer makes a change to a single file (view.jsp), and then pushes that update to the server via the sever-manager-web API. The server-manager-web will update the single file in the webapps/<context> deployed location. However this will not affect tomcat's jsp reloading logic since it is looking at the JSP that is in the temp directory due to the antiResouceLocking=true setting. What is interesting is that tomcat6 the context.xml file with the antiResourceLocking=true setting was still being set but tomcat6 doesn't seem to honor that setting. however, tomcat7 does now pay attention. This is going to break one of the key features of Remote development for plugins, being able to update just a single jsp/java/resource file in a portlet and avoid having to re-deploy the entire application which involves uploading potentially large war files and waiting for the redeploy/ reloading of context on server's side.
        Hide
        Gregory Amerson added a comment -

        The original reason this file was put in was this bug:
        http://issues.liferay.com/browse/LEP-4981

        It seems that people were unable to undeploy portlets using tomcat's update-manager due to windows file locking. I believe that we could fix this issue and only add the fix to liferay 6.1 and not backport it to enable the new style of remote development.

        Show
        Gregory Amerson added a comment - The original reason this file was put in was this bug: http://issues.liferay.com/browse/LEP-4981 It seems that people were unable to undeploy portlets using tomcat's update-manager due to windows file locking. I believe that we could fix this issue and only add the fix to liferay 6.1 and not backport it to enable the new style of remote development.
        Hide
        Gregory Amerson added a comment -

        Proposed fix is to simply remove automatically adding this context.xml to portlet plugins (or any other plugin where it would cause a problem for remote development). It seems that the problem this was meant to (unable to undeploy portlets using tomcat's update-manager) is very old. I believe the benefits of enabling delta-update feature in remote development outweights the negatives with not putting this in default.

        Show
        Gregory Amerson added a comment - Proposed fix is to simply remove automatically adding this context.xml to portlet plugins (or any other plugin where it would cause a problem for remote development). It seems that the problem this was meant to (unable to undeploy portlets using tomcat's update-manager) is very old. I believe the benefits of enabling delta-update feature in remote development outweights the negatives with not putting this in default.
        Hide
        Ryan Wan added a comment -

        PASSED Manual Testing following steps in Greg's comment.

        Reproduced on:
        Liferay IDE 1.4.0. Tomcat 7.0.22 + MySQL 5.1.58. 6.1.x revision 90445. Plugins Revision 89300.

        Fixed on:
        Liferay IDE 1.4.0. Tomcat 7.0.22 + MySQL 5.1.58. 6.1.x revision 90445. Plugins Revision 90445.

        Show
        Ryan Wan added a comment - PASSED Manual Testing following steps in Greg's comment. Reproduced on: Liferay IDE 1.4.0. Tomcat 7.0.22 + MySQL 5.1.58. 6.1.x revision 90445. Plugins Revision 89300. Fixed on: Liferay IDE 1.4.0. Tomcat 7.0.22 + MySQL 5.1.58. 6.1.x revision 90445. Plugins Revision 90445.
        Hide
        Gregory Amerson added a comment -

        Nice work!

        Show
        Gregory Amerson added a comment - Nice work!
        Hide
        Vicki Tsang added a comment -

        This is being bulk closed in preparation for the new workflow.

        Show
        Vicki Tsang added a comment - This is being bulk closed in preparation for the new workflow.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              3 years, 38 weeks, 4 days ago

              Development

                Structure Helper Panel