On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > Thanks for this thoughtful response, Craig. Very helpful. Notes are within: > > > On Mon, 29 Nov 2004 09:02:04 -0800, Craig McClanahan <[EMAIL PROTECTED]> > wrote: > > 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? > > Yup! Dang! LOL Nothing is free, is it? I have changed the factory > transfer state code to > > newApp.setState(existingApp.getState()); > > The people changing the implementation will know what state they want > to keep, to alter, or whatever, and this allows them to do it. In the > actual example of the AppImpl, I do with with a StateContainer. I > have made these changes in the > > http://131.191.32.112:8080/classes.zip >
That's better, but still requires me to be able to produce this artificial "state" object. It's not obvious to me what happens if that state information is modified (on another thread) while getState() is executing, if it includes live references to other "hot deploy" instances, and a few goodies like that. > file. > > > > > 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. > > The previous instance, when loaded, is replaced with the new version. > Or, do you mean generally? If you are talking about something like a > registry, then that is what my question on the previous email was > about. I am concerned that I be able to keep track of instances of an > implementation but not stop garbage collection. My head is not coming > up with interesting ideas on that one. I am sure that must exist. Do > you have a suggestion on that? Or, if I am not reading you right, > please elaborate. >From a simplistic viewpoint, I see IoC type frameworks being used in a couple of different ways: * "create on demand" -- every time I need an instance of a service object, I call the appropriate factory method, use this resource, and then throw away my reference to it. (Using JNDI resources normally also follows this model). * "create at startup" -- leverage the IoC architecture to configure the actual implementation class separately, and call the factory (or whatever) only once, at application startup; caching the object reference I get back. Convenienty, this object is also set up with whatever dependencies it needs (using constructor injection, setter injection, or whatever). My concern with your "hot deploy" strategy is that it works fine for the first case, but not at all for the second ... and people who just read the name are going to feel misled when they find that they can't transparently swap *existing* instances of the service object being used. They can only change the implementation class for *new* instances -- and that isn't any different from what an IoC container that allows configuration changes can do. > > > > > > 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. > > Yah. I have to agree on that one. That was just an extra which I > thought was neat but which might be too confusing. > > > > > 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. > > Explain, if you would, on the dynamic proxies. I think I know what > you mean but do not want to muddy the waters and would rather have you > elaborate a bit. Okay? "Eschew obfuscation and avoid metaphors 'til > the cows come home!" > >From JDK 1.3 onwards, you can create a class that *appears* to implement one or more particular interfaces, but doesn't really. This is an easy way to decorate existing objects to customize their behavior. The technique could be used to accomplish your idea of changing behavior on the fly -- but, of course, if you use "create on demand" and are using an IoC container that allows its configuration to be changed on the fly, then you don't even need dynamic proxies to change behavior at runtime. See "java.lang.reflect.Proxy" for more info. > Thanks, again, > > Jack > Craig > > > > > > > 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~ > > > > > > > > -- > > > > > "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]
