- This topic has 3 replies, 4 voices, and was last updated 20 years, 8 months ago by
.
-
Posts
-
Small problem – everything deploys perfectly fine, but when I try to redeploy, it doesn’t detect the new .war. If i touch (modify) application.xml or the .xml for the webapp, it redeploys.
Any way to automate this, or am I missing something?
Clay,
Any way to automate this, or am I missing something?
Well, it’s more like a point of clarification than actually missing something. Every application server decides through rules of its own when to do a full reload of an application. All seem to take modifications of JSP pages immediately. Most disregard servlet modifications until the application is undeployed and redeployed. Some will reload if you touch application.xml, some will not.
While our deployer ensures that all the files in the server deployment area exactly match those in your workspace, it does not automatically request a full reload of the application in the server. However, typically using the ‘Redeploy’ button will do this as a side effect, since it completely deletes and then replaces all the files in the server deployment area. However, it seems that Orion is clever and notices that the file modification time on application.xml hasn’t changed so it doesn’t trigger a redeployment.
In normal debug scenarios, you really shouldn’t need to ever use our ‘Redeploy’ option since the debugger will HotSwap your java code and the server will reload any JSP’s and our deployer will keep all modified files in sync. However, if you make substantial changes that do require a running Orion server to drop the current application and reload it, you simply have to touch application.xml to force it to do so.
Sorry for the confusion. I can see how seeing a button labeled ‘Redeploy’ would make you think we not only redeploy the application, but also force any running servers to reload it.
In the future we’ll be looking into supporting more “server-specific” behaviors so this will be one of the things we’ll be investigating.
–Scott
MyEclipse SupportAs I mentioned in a previous post, reloadling application configuration files (struts-config.xml, tiles-config.xml, ojb’s repository.xml are all kicked off by the act of running the load-on-startup servlets. Although it is clear that there are differences between the app servers in how they force restart, I think it would be worthwhile for you to invest in automation of this (server by server). Here is why. Several of these probably involve touch of some .xml file. That is fine, except this has impact on team. You could, under the covers, just touch the deployed version of this file, thereby saving the modification of the file for real stuff. This would avoid kludgy things like replace from HEAD when all you wanted was a container restart.
Wayne
Wayne,
The approach you propose is consistent with an ongoing internal discussion for the deployment system to support appserver-specific redeployment triggering. I’m moving this topic to the Enhancement forum where we can spec out the requirements for review and inclusion in a future MyEclipse release.
https://www.genuitec.com/forums/topic/appserver-specific-redeployment-your-input-requested/
Michael
MyEclipse Support
