>
> 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.
> >
> >
> >
> >
>
>