- This topic has 4 replies, 5 voices, and was last updated 21 years, 1 month ago by
.
-
Posts
-
Reported by Wk5657 on Support Forum:
As 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.
The approach you propose is consistent with an ongoing internal discussion for the deployment system to support appserver-specific redeployment triggering.
Michael
MyEclipse SupportA long standing Genuitec practice is to implement general functionality and then optimize as needed. Its our version of “1) Get it working, 2) Get it working right, 3) Only then make it fast.” We have an opportunity to optimize the exploded archive redeployment method to take advantage of appspecific redployment mechansims.
The MyEclipse R2.5.X exploded archive redeployment policy is to completely replace an existing deployment with the compiled codebase of the deployed MyEclipse project. This approach involves recursive deletion of the current deployment exploded archive followed by a recopy of the project’s binary codebase to the appserver’s deployment area. While this is a comprehensive method it suffers from 1) potentially expensive operation and 2) some appservers lock the deployed resources such that it is not really possible to perform a comprehensive code redeployment. The latter scenario typcially requires recycle of the appserver to remedy. Another issue with the current implicit reload mechanism is that touching a project resource to signal a reload request causes that resource to be out of sync w.r.t. the Team environment.
Here are some thoughts for your consideration and comment:
1) We think it is important to keep the current Redeployment process and semantics such that the concept of Deployment is always understood to be a process of packaging and (re)positioning application code to be loaded by an application server.
2) We think the addition of a Reload deployment action is useful. This action will use appserver specific mechanisms to instruct an appserver to reload a deployed application.
3) Following are application server mechanisms that we may employ to signal an appserver to reload an application:
Weblogic – Add a REDEPLOY file to each exploded deployment. When instructed to Reload an application the Weblogic Deployer will touch the application’s REDEPLOY file.
JBoss – When instructed to Reload the JBoss Deployer will touch the application’s application.xml file.
Oracle/Orion– When instructed to Reload an application the Oracle and Orion Deployers will touch the application’s application.xml file.
Tomcat -When instructed to Reload the Tomcat Deployer will <research/>.
Jetty – When instructed to Reload the Tomcat Deployer will <research/>
BEJY-Tiger – When instructed to Reload the Tomcat Deployer will <research/>
Your opinions and input appreciated.
Wayne
MyEclipse Project ManagerI agree with your thoughts above. Two things come to mind.
1). For Tomcat, web.xml may do the job – probably jetty also since these are web containers only and not EJB containers.
2). I think a more meaningful name for this capability is application restart instead of re-deploy. Using a name like that may clear up some of the potential confusion. Re-deploy is something that I want to do when my folder structure changes and it is rare. Restart is something I want to do when a file that is read at startup changes and it is common.Wayne
I agree with your basic approach of keeping the commonly understood default behaviou and allow manual execution of platform-specific actions. Just a few thoughts…
1) At least in Weblogic 7.0, hot deploy is not completely reliable for complex exploded EAR files.. I’ve seen what looks like a separate class loader for each EJB JAR… not good. so, in this case, I would want to run my server with auto-deploy disabled
2) Also re WebLogic 7.0… I have completly abandoned the use of REDEPLOY for most cases. With the new 2-phase deployment, it sometimes skips the first phase and just redeploys the old version of the EAR. So, I would recommend an UNDEPLOY followed by DEPLOY. This also has the benefit of really deactivating any existing containers.
3) On the other hand, exploded WAR inside exploded EAR is the “only” way most of my JSP developers want to work. Sometimes this is in conflict with my comments in (1) above. In these cases, I’ve deployed the EAR without the WAR file then separaately deployed an exploded WAR.
cheers
–Bill
