Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>Disclaimer:</strong> <em>I'm involved with JRebel development and therefore my answer might look a bit biased, but I'll do my best to explain.</em></p> <p>To answer this question I first want to draw your attention to the fact that one main difference among the names you have listed is: some of the solutions require you to change application design, others don't.</p> <p>Modularization solutions, like <strong>OSGi</strong> or <strong>JBoss Modules</strong> provide benefits if you follow the right path and <em>modularize</em> your application. Otherwise, if you deploy one silo bundle, it basically means you're restarting/redeploying the whole application, thus diminishing any benefits gained from this approach. </p> <p><strong>Play Framework</strong> is actually a full-stack framework that has the hot-deployment capabilities. Those capabilities vary depending on which version of the framework you use. But again, same story as with modularity - the framework enforces a certain programming model.</p> <p><strong>Apache Commons JCI</strong> isn't really a solution for hot updating the code. AFAIK, it just compiles and loads the class via new classloader. This also involves changing the application code as in the cases mentioned above. I'm not really sure if it is good or bad. The downside is that you hardly can do any broad integration with the ecosystem in this way. This approach is rather feasible for a self-made framework that would make use of this feature. Myself, I'd rather use a scripting language like Groovy, JRuby or JavaScript to achieve the same. Something like <a href="http://zeroturnaround.com/rebellabs/scripting-your-java-application-with-groovy/" rel="nofollow noreferrer">this</a>, for instance.</p> <p><strong>JRebel</strong>, <strong>Fakereplace</strong> and <strong>DCEVM</strong> - those guys do not care about the programming model. But the difference is quite big:</p> <p><strong>DCEVM</strong> patches the JVM and its goal is to provide a complete hotswap solution, which it does.</p> <p><strong>JRebel</strong> is a java agent (hooked with -javaagent VM argument), that instruments the application code and loads the new versions of the classes by versioning them. The main value of JRebel is that it provides flexible configuration along with a <a href="http://zeroturnaround.com/software/jrebel/features/frameworks/" rel="nofollow noreferrer">huge amount of framework specific integrations</a>, so that you can do a lot more than just a hotswap of java classes. For instance, add and autowire new beans in Spring application context, add new EJBs on the fly, and new Struts actions, etc.</p> <p><strong>Fakereplace</strong> is also an instrumenting agent, like <strong>JRebel</strong> but it has a lot less support for Java code changes (I assume) and the number of supported frameworks isn't as impressive.</p> <p><strong>Feenix</strong> can do as much as the Java Instrumentation API allows it to do. Which basically means it doesn't really add value on top of standard HotSwap of the JVM. Same for <strong>AgentSmith</strong></p> <p>UPDATE: this answer motivated the author of Feenix to come up with a new version - <strong>Feenix 2.0</strong> which resembles the way JRebel works with classes. But as the author says himself - Feenix is still vastly inferior to JRebel. There are also a couple of similar solutions, like <strong>HotswapAgent</strong> and <strong>Spring Loaded</strong> - those tools also provide similar functionality but limited in their own way.</p> <p><strong>Now a bit on your specific problem</strong>, how it could be solved with JRebel:</p> <p>Every module of the application should have its own configuration file, <a href="http://manuals.zeroturnaround.com/jrebel/standalone/config.html" rel="nofollow noreferrer">rebel.xml</a>. By module, we mean, either the EAR, WAR, or any of the JAR dependencies in WEB-INF/lib (like in your case) or server specific libraries. The configuration file with point to the directory where the compiled classes are and JRebel will load the classes directly from that location. This all means that you <strong>do not</strong> need to assemble the entire JAR once you make a change to a Java class. <strong>Instead</strong>, you make a change and compile the source (leverage the IDE, instead of a build script). The compiled class will be reloaded by JRebel once the class is invoked within the application code. </p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload