One technical constraint preventing hot redeployment is the lack of shared classes between applications in Java EE, this is required for many parts of GateIn.

So Java EE sucks :-)

(that being said, the WSRP JSF administration should be hot redeployable as it's a consumer of the shared classes).

Class sharing is a matter of classloader sharing, and all .wars share a parent classloader that contains classes in JBOSS_HOME/server/default/lib/*.jar or TOMCAT_HOME/lib/*.jar.

That's outside Java EE scope, true, but it's de-facto how all implementations do it so it's a real-world existing mechanism, and we're relying on it too :)

Those shared classes aren't hot-deployable though - it's just directories containing jars.

In JBoss it's possible to get very creative with classloader hierarchies, but it requires extra configuration, and then extra configuration for user .war / .ear as well so that they can participate in these custom classloaders. Maybe that could be done automatically via custom deployers if only we could reliably identify user .ear/.wars containing portal apps (maybe if they contain portlet.xml?).

The kernel problem is that it should respond to some undeploy / redeploy events fired by jboss, and remove services from its RootContainer and PortalContainer, then rescan only redeployed archives to read configuration, and instantiate, inject, init / start the services and other picocontainer components.

We have WCI layer to provide integration with container. Maybe we could add deploy / undeploy callbacks there, with different wiring for Tomcat and JBoss. Although at the moment kernel doesn't actually interact with WCI, I think it's completely separate.