> -----Original Message----- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: 29 November 2004 01:55 > To: Struts Developers List; Dakota Jack > Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) > [was Re: Chain enhancement idea] > > > On Sun, 28 Nov 2004 15:36:27 -0800, Dakota Jack > <[EMAIL PROTECTED]> wrote: > [snip] > > With hot deploy, instead of switching the implementation > and the name > > of the implementation class, e.g. ColonSeparatedMovieFinder for > > DatabaseMovieFinder, you just have an implementation called > > MovieFinderImplementation (or whatever you want, e.g. X) and a > > MovieFinderImplementationHotFactory for getting object instance > > implementations of the MovieFinder interfaces. > Conceivably, in fact, > > you can give people differing implementations with the same name by > > simply putting them in different directories: no problem. > This means > > that the code can be dynamic and alterable at will and that > there need > > be no changes anywhere if you don't want there to be other than > > dumping the new MovieFinderImplemenation.class in some directory > > somewhere. > > Within a single JVM (such as a servlet container), the only way to > have different versions of the same fully qualified class name is to > use different class loaders, which loads the different versions from > lots of different places. That sounds like a pretty significant code > management issue that any hot deploy strategy like what you describe > would need to deal with. > > On the other hand, you're going to need individual class loaders to > solve a different aspect of "hot deploy" as well ... recompiling an > existing implementation class to modify its behavior (instead of > trying to switch to a new one). There is no ClassLoader.unloadClass() > method in Java, so the only way to "throw away" an old class is to > throw away the class loader that contained it (and hope that the rest > of the application doesn't have any pointers to the old class or any > instances created by it, which would cause a big memory leak). > > That's what a servlet container does, for instance, when you reload an > app -- it throws away the old context class loader and creates a new > one. It's not a perfect solution, but it's not an easy problem, > either. > > Craig >
Late to this thread, but "hot deployment" is quite difficult to achieve inside a framework without very careful programming for very reason that Craig explained above. First, you need to solve the problem of deciding when the use of object is finished (pre garbage collect state) before you can ever remove the class. Since objects are based on classes you must know when it safe to discard the object. Second, if you need to invent a standard scheme to reload the class, if some external event (e.g a file modification time change in your native operating system) occurs. Third, decide about versioning with your (hot deployable) classes. What if I replace the current version of a class B with an ancient version A? Now if the number of classes of A is less than the number of classes of B, then you must loop right back to the first to the first problem. Hence WebLogic etc have Admin Server and Managed Server to handle application and web container requirements, but it would be harder to further divide this macro architecture into more finer architecture and also have good ease-of-development & deployment. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
