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

On Wed, 2011-01-26 at 22:23 +0100, Julien Viet wrote: > why do one's need hot redeploy ? I don't think hot deploy/undeploy/redeploy is really that important. What I do think is important is that deploy/undeploy/redeploy can be done. Right now we can't do this with the extension mechanism, we can only add a page or a portlet when the server first starts. > > 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. >> >> >> >> > >