Just a few notes and more later after some thought:
On Mon, 29 Nov 2004 17:01:43 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Mon, 29 Nov 2004 15:04:48 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > 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. No StateContainer needs to be created. I just did in this case. In fact, we need not even update the state at all. This is an extra which neither Dependancy Injection nor Service Locator provide. > > 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 am not sure what you mean by "transparently swap". IoC requires fairly extensive configuration for this "transparency". I don't see what is transparent about the IoC setting of an implementation at all. Am I missing something? The difference is that an IoC container requires configuration changes and a class. This requires only the class. I don't think that IoC containers generally use different classes of the sort we are discussing without other changes. RIght? This is so, for example, when we switch from one database to another. We don't just change the configuration. We also have to provide the database. That is what I am doing except without the configuration change. > 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. I am familiar with Proxy, though no expert, and have coded them in conjunction with the code I am showing you. I won't send that along yet to keep things simple. But, I am not seeing what you are thinking. Presently, I am convinced, there is something to what I am looking at if I can create a registry without crashing the garbage collection mechanism in Java. Thanks again. I am enjoying the converstation. 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]
