If I'm reading the code right, your "factory" for any given class has to know a bunch of nitty gritty details in order to implement the transferState() method, right? So, whenever I add new state information to the application class, I have to update transferState() as well?
I don't see any mechanism to replace references to previous instances of a newly loaded implementation class -- without that, "hot" deploy doesn't seem particularly useful. Or, for that matter, any mechanism to suspend access to the "old" instance while the state is being transferred. I definitely don't like the notion of having more than one class with the same name floating around ... that's just asking for confusion and problems in debugging. Overall, it seems like an interesting attempt to do the kinds of things that implementation inheritance (using more typical service locator patterns), and/or (JDK 1.3 or later) dynamic proxies, let you deal with in ways that are more to my personal taste. Craig On Mon, 29 Nov 2004 00:59:43 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > 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]
