On Mon, 29 Nov 2004 22:29:35 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> Thanks, Craig. I think there might be a misunderstanding. See within.
>
>
>
>
> On Mon, 29 Nov 2004 18:32:06 -0800, Craig McClanahan <[EMAIL PROTECTED]>
> wrote:
> > On Mon, 29 Nov 2004 17:36:09 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote:
> >
> > > 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?
> >
> > If I use "create at startup", I'm going to get my instance of a
> > service class configured with its own dependencies. For example, if
> > I'm using constructor injection:
> >
> > public class Foo {
> > public Foo(Bar bar) {
> > this.bar = bar;
> > }
> > ... code that uses "bar" ...
> > }
> >
>
> So far the comparison is this: IoC creates the implementation of the
> Bar class with configuration and so on at startup. There has to be a
> class somewhere, of course, which is the implementation that IoC plugs
> into the app. HaD just starts with this class sitting where the
> implementation class is supposed to be. Your class might be called
> "BarTypeXImpl". My class is always called "BarImpl" merely.
>
> So far, all HaD requires none of the considerable coding overhead
> required by dependancy injection. (I hope I don't sound negative
> about lightweight, IoC containers, because I am not. Just looking
> around here.)
>
> Now, if you want to change the implementation class to, say,
> "BarTypeYImpl", you have to change the configuration and restart the
> application. I just drop call this new implementation by the same
> name ("BarImpl") and drop it in place of the old implementation.
> Then, I call BarHotFactory.loadBarImpl(). The result is that the Bar
> class reference and the Bar classloader class reference are changed to
> the new BarImpl. There will be no straggler references to cause
> garbage collection problems, I now see.
>
>
> > Now, in your scheme you upgrade the Bar class (of course, setting up a
> > new class loader to contain it).
>
> This only happens when there is a change. The IoC has also to do something.
>
> > But what you haven't done is
> > notified my Foo instance that you should somehow update the private
> > "bar" variable to point at a new instance based on the new class
> > (possibly having to do some sort of state transfer as well) ... it
> > continues to use the old one -- with the side effect that the old one
> > will not get garbage collected either.
>
> This is, I think, mistaken. Isn't it? The class reference content
> has changed. The reference Bar has to a classloader and the reference
> Bar has to a class remains the same but points to a different entity.
> Right?
Only partly. The renference to the old version of "Bar" remains in
existence fo the lifetime of the "Foo" instance that contains it,
until the "Foo" instance is told to release the old reference.
So, when Foo no longer uses Bar, Bar will be garbage
> collected. The sole result that is of significance is that Bar has
> been updated but the Bar in Foo is using the old version. Right? All
> new Bars created in Foo will be the new version. All new Foos will
> create new Bars. Right?
Yes, but so what? It's the existing Foos that will be broken by your change.
Updating the bytecodes that your factory method returns for a
getInstance() method for a Bar class has nothing to do with any
existing object that uses a Bar object as a service, and maintains a
reference to that instance.
You could get away with what you're after if Java supported
ClassLoader.unloacClass() -- but it doesn't for valid technical
reasons.
>
> If we want all client Foos to use the newest and greatest Bars, we can
> do so by restarting the application. This is the same thing we have
> to do with IoC, or we can get a solution for HaD that wil mirror any
> solution for IoC. So, the sole problem is that HaD can do things that
> IoC cannot do. You don't have to do that. Correct?
>
Restarting the application works (for this particular scenario) ...
but it makes any attempt to pretend to do "hot deploy" pretty
pointless - the newly restarted app will already pick up the new
version of your implementation class, without any special attention on
the part of the app itself. There is no need, if you're willing to
restart the app, to do anything like this.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
