The word “hot deploy” used above may not reflect its original meaning, not only because my poor English, but also because (Vietnamese) developers have different concepts of it: “automatic hot swap”, “automatic redeploy webapp”, “automatic restart container” .
This is how I understand the differences:
1/ Hot deploy container: automatic restart whole servlet container (Tomcat)
2/ Hot deploy webapp: automatic reload context root and all classes of respective webapp.
3/ Hot deploy classes: hot-swap only the re-compiled classes (runtime)
It is obvious that #1 is slower than #2 and #2 is slower than #3: Hot-swap or hot-code replacing .
Ok, now what? Let’s try to reduce the hot-deploy time in Java developement in the well-known combination: Eclipse + WTP plugins + Tomcat. Assumed that you already have an Eclipse with WTP/WST plugins installed (e.g. Eclipse JavaEE version).
From the New menu, select Other… -> Server -> Server. For your server type (probably “Apache Tomcat 6″), specify the path to your Tomcat installation directory, e.g.“/opt/apache-tomcat-6.0.18″ or “D:\USR\apache-tomcat-6.0.18″ . Add your web project as a ‘Resource’ to this server (you may modify the context root first).
Double click on the Server in your Server view (its name is something like “Tomcat v6.0 Server at localhost-config”), it will display the “Overview” tab:
The main settings for hot-deploy here:
Once you started the web-app in Debug (right click -> choose “Debug…”), the changes you make to your JSPs or inside Java methods will be instantly hotswapped into your running webapp, therefore reduce the development time (at least the wasted time looking at console when reloading web-app)
Since Java 1.4.2 , the JPDA supports hot-swap classes on debug mode, by manipulating class loaders at runtime. Eclipse makes use of it via WTP under the name Hot Code Replace . Setting auto-publish helps replacing text files and recompiled jar, but not for classes. By default, Tomcat’s context reloading will reload all classes using its class loaders and therefore does not take advantage of hot-deployed classes.
Note that JPDA is not the best solution for hot code replacing, the proven one here must be either JRebel or DynamicCodeEvolution. Some web frameworks (Tapestry, Stripes, Wicket, Grails, Roo) also has their own classloader handlings to support quick reload. They’re all inspired by some standalone JAR files around which I don’t remember (probably the pioneers for JRebel). And FYI, Tomcat Sysdeo plugin and Jetty can also support HCR , in case you don’t want to use Tomcat WTP.
Running Tomcat in Eclipse (via WTP plugin) is a bit slower than via external command, and running in Debug mode is somehow resource-hogging, which may result in errors like hot-swap failure or OutOfMemoryError . To avoid those issues, you may try some JVM options via Tomcat JRE params: Double-click on your server in the “Servers” view, switch to the “Overview” tab, click on the “Open launch configuration” link, switch to the Arguments tab; there you can add relevant memory settings to the “VM Arguments” section
-client -Djava.awt.headless=true
-Xmx1024m
-Xms256m
-XX:MaxPermSize=1024m
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+UseConcMarkSweepGC
JPDA HCR not applied: to change the signature of a class (add/remove methods or fields) or to add new classes on the fly. Additionally, some method calls (“stack frames”) can’t be modified, including the main method or any method invoked via reflection, that is, by usingjava.lang.reflect.Method.invoke().
(JRebel and DynamicCodeEvolution can overcome those limitations)
Eclipse WTP Tomcat hot deploy,布布扣,bubuko.com
原文:http://www.cnblogs.com/zeng200103/p/3867502.html