Hot deploy is a very neat feature that people expect nowadays, but yes it's true, fast startup is even more important and if fast enough, it can offset the lack of hot-deploy. But I think making deploy / undeploy to function would force us to properly implement and give more thought to some of the things, and I think there are scenarios (more than I can imagine) where lack of it is a hurdle.

I'm thinking things like:

- component modularization

Looks like WSRP attempts either exposed some lack of clean portal - components separation, or maybe there's just a lack of understanding the facilities in place, and how to use them properly.

- automated testing

Let's think Shrinkwrap / Arquillian style of testing ... Programmatically compose a test archive, start container, deploy the test archive and execute  tests. 

Currently to test things with GateIn you have to do that upside down: place tests into deploy first, then start the container, then trigger test execution. Completely different (and surprising) flow. I'm guessing, but seems to me this might be the reason that's holding back GateIn support in Arquillian.

- cleanup after component is removed (that's handy for testing)

If added component registers stuff in JCR, creates pages, navigations ... is there a simple way for configurations to get removed if component is undeployed?

That would be very useful for testing. Or, transient storage could be configured for testing ... but would have to be prefilled with some initial portal data to prevent first-time init upon every start.

Maybe someone can think of some more scenarios related to this ...

On Wed, Jan 26, 2011 at 10:36 PM, Matt Wringe <mwringe@redhat.com> wrote:

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

_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev