Eclipse WTP Tomcat hot deploy

標籤：des   http   java   os   strong   io   for   art   

轉自： http://ducquoc.wordpress.com/2010/11/06/eclipse-wtp-tomcat-hot-deploy/
One of the reasons why JavaEE does not have many succesful projects is that its development time is usually longer than other competitors’ time (PHP, Ruby, Python, ASP.NET, …) . Ok, we all know the burden of overly complicated design and over-engineered implementations from Sun, so let’s skip them and go to the one to be resolved: the Hot-Deploy time. In other words, the time for developers to see the web-page refreshed with their changes applied. 

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” .

Hot deploy concepts

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).

Create a New Server WTP for web apps

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).

Adjust the server’s settings

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:

• Server location: Use Tomcat installation (actually, either “workspace metadata” or“custom location” can work as well, but let’s use the most simple for beginners’ sake)
• Port: modify the HTTP port from 8080 to the one you desire. You may also modify the remaining 2 ports respectively to avoid port conflicts between Tomcat instances.
• Timeout: better increase them 100 or 200 seconds more.
• Server options: not necessary to check any options.

Enable classes hot-swap

The main settings for hot-deploy here:

• Publishing: Auto publish when resources changes (so as to hot-deploy text resources like .properties, .html, .jsp, … and packaged resources like .jar, .zip ) , the interval should be small (1 or 0 sec).
• Switch to “Modules” tab, since you already added the web app to the server, there should be at least a “module” with the specified context root (path URL). Select that module, then click “Edit” button, uncheck the “Auto reloading enabled” checkbox, click OK. Now your module should have “Auto Reload” setting as disabled (equivalence to <Context reloadable=”false” … /> in server.xml/context.xml of Tomcat)
• Save the changes (at least make sure the two above has been applied already).

Start the server in Debug mode

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)

Why?

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.

Some more recommended settings

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

Limitations

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)