Re: [gatein-dev] Extracting WSRP (modularization of services and configuration)?

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.