The way the dynamics work in OSGi is only partly classloading. In the HTTP examples, we have defined an HttpService where you register a servlet. When a bundle (OSGi JAR) is started, it registers a servlet with the http service. When it is stopped, the Http Service detects this and removes the mapping. When you update the bundle, the bundle is first stopped, automatically cleaning up the servlet registration. Then the code is replaced though the old code remains in memory because other bundles could still import packages from this bundle. This remains until the packages are "refreshed". This will create a dependency graph of all affected bundles, stop these and start them again with a new class loader.
So there is no "magic". The key trick is that bundles have their own classloader and we can start and activate them as well as stop them at any moment in time. Obviously this works only if you make your bundles proper modules with loose coupling. If classes are shared between bundles willy nilly refreshing the packages will be a full restart. Neither is it of course completely gapless. However, many, many people have installations where they replace their bundles with servlets on the fly because the Http server rarely if ever has a dependency on the application code. Kind regards, Peter Kriens Costin Manolache-2 wrote: > > On Fri, Apr 25, 2008 at 12:49 AM, David Jencks <[EMAIL PROTECTED]> > wrote: >> >> On Apr 24, 2008, at 11:11 PM, Henri Gomez wrote: >> >> >> > >> > > I've heard various claims of this nature from osgi zealots, but when >> > > talking to apparent experts the only things resembling this they >> seemed >> to >> > > know about were grad student experiments that did not have production >> use as >> > > even a far-in-the-future goal. Do you know of any actual examples of >> this >> > > kind of behavior that actually work under load? >> > > >> > >> > We'll see how OSGI works underload with Glassfish v3. >> > >> >> Are they planning to support "gapless" redeployment of web apps using >> only >> osgi features, with no other servlet container support? If so is can you >> point to an explanation of how they plan to do this? > > There are many problems to solve for 'gapless' redeployment, but I > think the biggest is > sessions and statics. The classloader ( OSGI or not ) can keep > multiple versions of > the application loaded - but you need the mapper to know where to send > each request. > In theory it could be done even with the current tomcat, by including > the version in the cookie and changing the mapper to use it. > > But I think the main question is if it's worth it - there is a lot of > complexity and many things that can go wrong. Very few advanced users > will be able to use this - in particular if they have production > environments and some release testing is required ( i.e. it would be > quite hard to automate and test what will happen in gapless case). The > alternative - having multiple machines/VMs running different versions > behind a load balancer - is quite safe and I suspect the 'advanced > users' who may need gapless would be better off using the old way. > I mean - if you run your app out of a single VM, probably you won't > need gapless, and if you already have load balancing/failover/multiple > servers - you have a better/safer solution. > > Costin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Osgifing-Tomcat-tp16830131p16930343.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
