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

why do one's need hot redeploy ?

if it's to increase productivity, I don't believe in that solution anymore because the complexity to make it real in a server agnostic manner is very high. However, I do believe in providing a server that is so quick to boot that redeploy is not necessary anymore, or is not perceived as a value add. If you take GateIn on Tomcat, it starts in 25 seconds (first one). It used to boot in 18s seconds one year ago, at this time, the boot time was roughly divided into - Tomcat deployment and web app scanning : 5 seconds - JCR init 7 seconds - XML parsing 3 seconds (JAXB and JBoss XB) - various other things for the rest of the time - I know that the JCR team is working on improving startup time of JCR (it lost seconds because of the switch to JBoss Cache, which is slow to start and they start like 18 cache instances but they are now able to collocate a single instance). - We will decrease XML parsing by getting rid of *XB , it's just a matter of rewriting XML deployment parsing. - We can also decrease web app deployment if we deploy less web applications. I know that JBoss is also working on making AS7 blazing fast to boot and they will achieve it because they took the right decisions. Therefore instead of taking the decision to do R&D to provide hot redeploy, I would instead take the decision to work on reducing the server boot time. So the real challenge is: do you think we can make GateIn boot in 10 seconds (Tomcat / AS7 / Jetty) ? On Jan 26, 2011, at 9:42 PM, Marko Strukelj wrote: > > 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. > > > >