Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <31DF72A980E5D511B48C000102BD8685061DB306@calexc01.diginsite.com>
From: Ralph Goers <Ralph.Goers@digitalinsight.com>
To: "'dev@cocoon.apache.org'" <dev@cocoon.apache.org>
Subject: RE: [Kernel22] How to develop a component?
Date: Thu, 8 Apr 2004 07:48:17 -0700 
MIME-Version: 1.0
Content-Type: text/plain

Sorry, but this cannot work.  Calling comp.ensureWired() accomplishes
nothing because the component could be dropped between completion of that
call and the next.

This whole idea will create the ugliest client code you have ever seen,
because each and every operation could fail, in which case you will have to
start over again from the beginning, or fail the whole thing (and probably
make somebody else retry the whole thing).  

I'm with Sylvain on this one. Don't get rid of the block until it is
released.

Ralph

-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] 
Sent: Thursday, April 08, 2004 7:38 AM
To: dev@cocoon.apache.org
Subject: RE: [Kernel22] How to develop a component?


Believe me, I'm really just curious. Would the new code be the same
or just similar? Of course the lookup is different as a different
method is used. From what I understood the code would look like
this:

    StatefulComponent comp =
(StatefulComponent)wire.lookup(StatefulComponent.class, SOMEHINT);
    try {
        comp.login ();
        // (1)
        comp.doOperation ();
        comp.logout ();
    } finally {
        wire.release (comp);
    }

> 
> The new "Block" code uses Wirings instead of a 
> ComponentManager/ServiceManager, but they are *very* similar. 
> You should also include a
> comp.ensureWired() call
> at the top, to test if the block whose components you are 
> using hasn't been reloaded since you last checked. (This call 
> will also reload the block if it is scheduled for reload, but 
> not yet reloaded).
So, would I do a comp.ensureWired() before each call to the component?

> 
> ***The biggest change however***, is that you have to be 
> prepared for the event that a component that you have looked 
> up may disappear due to block reloading.
> 
> This simply did not happen with Avalon. So you may get an 
> exception where you didn't get one before.
> 
> Otherwise you should be fine.
> 
So, if I understand you correctly, the only difference is that I
can get an exception that I wasn't prepared to get when using
Avalon. If that's try then I don't see any reason why this
wouldn't work with using the Avalon interfaces - I'm just
speaking of the interfaces not the implementation!

Carsten