Jetty中的热代码部署

Question

I am writing a Java EE application, using Jetty as the app server for convenience during development. Although (re)deployment is fast, I'd like if it was possible for Java code changes to be reflected immediately in the running server without restarting. (I'm already using the useFileMappedBuffer setting to see immediate changes to statically served content).

I've seen questions about using the Maven Jetty plugin and setting scanInterval in order to redeploy a web context, but that's not what I want to do. My Jetty server is started from within a Java application in Eclipse and I'd like code changes to be immediately reflected in the running server, as is possible with ordinary Java applications in Eclipse. I'm running the code "in place", ie not building and deploying a WAR file first.

I realise that web apps have their own class loaders in order to conform to the servlet spec, but I don't mind risking non-standard behaviour to get changes deployed more rapidly in development. I've tried using WebAppContext.setClassLoader to set the classloader to a "normal" classloader but to no avail.

Is it possible to do what I want? I believe JRebel claims to do it, but what's it doing that I'm not?

Answer 1

If you connect to Jetty using remote debug from Eclipse, Hot code replace should be possible.

Remote debugging is enabled by adding following to Jetty start script:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8787

Answer 2

Even the ordinary Java application needs to be restarted to see code changes.

Basically your options are:

1. Restart Jetty (you said you don't want that).
2. Make Jetty scan for application changes and allow hot redeploy if changes are detected (you said you don't want that).
3. Attach a remote debugger which then does hot-swap your code changes (see answer of Amila). This is limited to method body changes and therefore not really useful.
4. Use JRebel which provides a useful hot-swap implementation and also can pick up configuration changes for many frameworks.
5. Use a web framework which implements a proprietary hot-swap implementation based on throw-away-classloaders (eg Tapestry or Civilian ).