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

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: None
• Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
• Component/s: Infrastructure > App Servers, Tools > Plugins SDK > Portlets
• Labels:
  • QA-R
• Similar Issues: Show 5 results ; ;

  LPS-21405	jboss bundle does not configuration jsp reloading development setting
  LPS-25530	AMS portlet has been updated to account for new changes with alloy controller
  LPS-23876	Updating a basic web content article that has a validation error will return exceptions on reload of page
  LPS-18992	Delta selector dissappears when results number is lower that delta
  LPS-5411	Theme deploy fail when update a theme

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.

[Gregory Amerson]

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.

[Gregory Amerson]

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.

[Gregory Amerson]

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.

[Ryan Wan]

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.

[Gregory Amerson]

Nice work!

[Vicki Tsang]

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