What is most urgently needed is: (1) the ability to efficiently "redeploy", under the assumption that the metamodel has not changed. So the internal implementation of the components might have changed, but there is no reason to actually restart the EJB container and the webapp. (2) the ability to do this without losing the state of existing SFSB instances and the HttpSession. The slowest part of the compile-deploy-test cycle today is logging back into the application and getting to the page you want to test. anonymous wrote : I'm pretty sure that a schema change to a .class file will generate a different SerialVersionUUID for default serialization. So, we would need to use JBoss Serialization to ignore version id mismatches. Or just tell the user to add a serialVersionUID to their classes. Easy, I don't see them minding that. For SFSBs, we could probably do it for them. anonymous wrote : I don't know if a schema change (an additional field added) would break the serialized HTTP Session/SFSB Session on deserialization. Changing (adding/removing) a non-transient field definitely would break standard Java serialization, but there is no reason for it to need to break JBoss serialization, since there is an incredibly natural and trivial way you can define this: (1) if a field has been added, set it to Java language default (2) if a field has been removed, throw away its state (3) if the field type has changed, try to typecase This is of course what dynamic languages do in the same situation. anonymous wrote : Because of both of these problems, I think just using the IDE to do non-schema code changes during and within a test run is good enough. This is definitely not true. The problem with using IDEs and HotSwap to debug JBoss is that as soon as a single schema change occurs, HotSwap stops working until you restart the whole JBoss process. Redeploying the webapp is NOT enough to get HotSwap working again, because the IDE does not see that as a class reload. Try this in eclipse. As soon as you make one single schema change to any class, HotSwap is hosed until you restart JBoss. Of course, this is totally crap, but that tells you how crap HotSwap is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988587#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...