Jack, Peter's point ``Hot Deployment'' can be located in Chapter 2 p29-34
http://www.develop.com/us/technology/developmentorseriesdownload.aspx?id =11 Shed. ~~~~ Way out of my league ~~~~ -----Original Message----- From: Pilgrim, Peter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 30, 2004 6:16 To: 'Struts Developers List' Cc: [EMAIL PROTECTED] Subject: RE: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) [was Re: Chain enhancement idea] I think I got a book at home in the attic that went into so-called ``Hot Deployment'' in great detail. (Been a year since I last looked at it for generic service locator idea, in the end I found myself looking at IoC / Dependency Injections pattern.) It is addison wesley from 2001-2002. Let me google for you ... Yep! Here it is http://www.amazon.co.uk/exec/obidos/ASIN/0201753065/qid=1101813082/sr=1- 5/ref=sr_1_2_5/202-3643115-2068623 # "Component Development for the Java Platform (DevelopMentor Series)" # by Stuart Halloway # Paperback 304 pages (January 7, 2002) # Publisher: Addison Wesley # ISBN: 0201753065 This is where I got my information from that Hot Deployment is hard to achieve in Java without careful programming. I think you ask too much for developers of an application frameworks to follow strict programming rules in whatever hot deployment scheme you invent. Let's it was so simple we'd all be doing it. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 > -----Original Message----- > From: Dakota Jack [mailto:[EMAIL PROTECTED] > Sent: 29 November 2004 09:00 > To: Struts Developers List > Cc: [EMAIL PROTECTED] > Subject: Re: Think Tank Thread on IoC, CoR, and HaD (hot arse deploy) > [was Re: Chain enhancement idea] > > > Here is code, as opposed to "pretty pictures" -- LOL ;-) > > This is intended to demonstrate how simple Had is in contrast to > normal Service Locator or Inversion of Control (Dependency Injection) > frameworks. Remember, THIS IS ALL THE CODE. There are no > NanoContainers. Not XML. No Config classes, etc. Where you want to > have a single class with potential changes in implementations, you > simply do not change the name of the class, e.g. provide new > implementations under the same name. Where you want implementations > that are different, e.g. if the Action class were an interface, you > simply use different names for the different implementations and then > you can hot deploy variations on the code in classes with those names. > This allows you to change an existing implementation radically either > by hot deploy or by name. Which you want to do depends on the > situation. ActionServlet would want to be, for example, an interface > that allowed differing implementations under "ActionServlet" without > having different named implemenations, like you have with IoC and > Service Locator solutions. On the other hand, you also would get hot > deploy of various Action implementations under different names, e.g. > LogonAction, PublishAction, etc. > > A working application with the App interface and client tester is > available in a zip file, classes.zip, at > > > http://131.191.32.112:8080/classes.zip > > > This code has some additions that allow us to see whether or not a > particular object has the last loaded implementation of AppImpl. The > code includes: > > App.java > AppImpl.java > AppHotFactory.java > TestAppClientTester.java > SiteConstant.java > Classpath.java.java > > To use a new AppImpl, all you have to do is to drop the AppImpl.class > into the classes/deploy/com/crackwillow/app directory and call > AppHotFactory.loadAppImpl(). > > To see the "name" command work with the client, start the client with > java com.crackwillow.testing.TestAppClientTester NEW_NAME > > > Jack > > > > > > -- > > > "You can't wake a person who is pretending to be asleep." > > ~Native Proverb~ > > "Each man is good in His sight. It is not necessary for > eagles to be crows." > > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ======================================================================== ====== 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]
smime.p7s
Description: S/MIME cryptographic signature
