"sacha.labourey(a)jboss.com" wrote : Concerning the "clean redeploy" of classes, instead of relying on facing hotswap behaviour or similar, why not use a simpler approach where we would load the NEW classes in a new Classloading tree and start routing new requests to that classes tree once it has been properly loaded? This idea only addresses the use case where zero "metadata-sources" have changed on disk. By a metadata-source I mean an ejb-jar.xml file, a bean class, or a business interface. If a metadata-source changes, you're gonna have to be real careful on how changes are merged with the old metadata. anonymous wrote : | The trick is to make sure that the SAME "containers" and services are able to work on multiple classes trees (and, for example, keep a single version of a cache, or a lock table, of a transaction table, etc. => services and containers would rely on specific ID, not on specific class instances) | | That way, if you have a long running requests being processed, this request can continue in parallel with new requests. The old request would keep using the old classes definition while new requests could use the new class definitions. | | That could also speed up app re-deployment A LOT: there wouldn't be this huge gap anymore between the undeploy of version 1 and the total redeploy of version 2: instead, any requests would be able to keep using version 1 while we fully load version 2 and at that time, we can do a micro-switch that would route any incomnig request to the new class tree. This could certainly be easily handled by using the per-container/per-request METADATA i.e. the class tree to use would be specified in the METADATA and used dynamically at runtime by the containers/services. | | That means we could also support, in a more "production" kind of environment, stable "switch of releases" i.e. JBoss ON could distribute a new version of an application to 50 nodes of a cluster, PREPARE the application by loading it in a new class tree and, once all nodes have successfuly loaded the new tree, you atomically re-route all new requests to this new app => standby mode for pre-loaded apps. This scenario is probably slightly more complex as it would probaly require a change in metadata, hence is possibly a different scenario. You're talking more about applications in production, while this thread is focused more on zero turnaround in development. For this case, it doesn't matter much on how fast the creation of the new metadata (or container) is, just that the swap from the old version to the new is superfast and seemless to the application. What this thread is discussing is getting closer to the zero turnaround time of Rails in development so that Java EE/JBoss can be used in RAD environments more viably and closer to the productivity that Rails brags about (and so that people don't use gay scripting language to do development). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989358#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...