Disclaimer: I'm involved with JRebel development and therefore my answer might look a bit biased, but I'll do my best to explain.
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.
Modularization solutions, like OSGi or JBoss Modules provide benefits if you follow the right path and modularize 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.
Play Framework 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.
Apache Commons JCI 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 this, for instance.
JRebel, Fakereplace and DCEVM - those guys do not care about the programming model. But the difference is quite big:
DCEVM patches the JVM and its goal is to provide a complete hotswap solution, which it does.
JRebel 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 huge amount of framework specific integrations, 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.
Fakereplace is also an instrumenting agent, like JRebel but it has a lot less support for Java code changes (I assume) and the number of supported frameworks isn't as impressive.
Feenix 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 AgentSmith
UPDATE: this answer motivated the author of Feenix to come up with a new version - Feenix 2.0 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 HotswapAgent and Spring Loaded - those tools also provide similar functionality but limited in their own way.
Now a bit on your specific problem, how it could be solved with JRebel:
Every module of the application should have its own configuration file, rebel.xml. 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 do not need to assemble the entire JAR once you make a change to a Java class. Instead, 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.
