Do we really need hotswappability?
This is also a problem because Avalon doesn't have the notion of hotswappability and I'm not sure that the component loading model can be turned into one that can work in such an environment (consider that avalon loads components by String reference, while the new kernel uses pointers to interfaces as Class).
Is it worth the price to pay for the complexity?
I'll try to be very pragmatic and add just a couple of lines here:
1. if you are running a simple system, reloading is not necessarily a pain, and this is true for the far majority of us;
2. if you're running an "enterprise class" thing, the reload problem from the disruption of service has been solved for you in a number of ways, e.g. load balancers: you (gently) stop one machine at a time and perform your upgrade.
The only scenario I can think of where hot swappability can be really useful is for high-traffic and extensively cache based system (with no persistent cache, just in-memory). If your application (and I've hit into some of those) starts performing reasonably well only after a long period of warmup, then you'd really love hot swappability. But building a generic framework only to solve this very specific issue might be overkill.
It all depends on what is exactly the price to pay for the complexity: I'm dreaming of having the Cocoon kernel support both behaviours, where you mark your block as "hotswappable" only if you're sure about it (which, mind you, might happen in a lot of cases: think about application blocks made of sitemaps, stylesheets, flowscript and resources).
I don't want to run into Java's Serializable nightmare, though. And I have no clue on how to avoid it.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
