avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [Summary] Avalon 5 ComponentManager interface
Date Wed, 12 Jun 2002 12:23:27 GMT


Leo:

Thanks for the overview.
I've included a bunch of in-line comments - most to do with pulling
out extra information concerning the way this is going to be used, and
a couple of commonts on preferences I have in certain areas.


Leo Sutic wrote:

>All,
>
>this is my understanding of the sort-of concensus we have arrived at.
>Some issues are still being debated, and I believe I have marked those
>as such.
>
>The ComponentManager interface:
>
>interface ComponentManager {
>  /**
>   * Issues:
>   *
>   * - Should it throw Exceptions on failed lookup or return null?
>   */
>  public Object lookup (String role);
>

My preference is for the maintenace of the current exception declaration.

>
>
>  /**
>   * Issues:
>   *
>   * - Should it throw Exceptions on failed lookup or return null?
>   * - Should it exist at all?
>   * - Should the hint be a String?
>   */
>  public Object lookup (String role, Object hint);
>}
>

Two questions here.
1. Do you have examples of cases where the role and hint cannot reasonably
   be expressed as an opaque string ?
2. If a hint value is required - could it be formalized into a typed
   structure that could be built by a generic kernel?

>
>
>We've agreed on removing release() from the CM interface, and the rest
>of this sumary details how we get the same functionality without
>that method.
>
>We've agreed that all components returned from a CM are thread safe.
>
>Borrowing from Robert Mouat's mail:
>
>transaction:
>
>  this is the period during which a component can be expected to hold
>  a [non-memory] resource.  This depends a lot on the interface, and
>  I'm going to divide these into 3 categories:
>
>  1. The interface defines no transaction. e.g. those that can be
>  implemented in a thread-safe manner. e.g.
>
>    interface DocumentStore
>    {
>      public Document getDocument( String ref );
>      public void putDocument( String ref, Document doc );
>    }
>
>  2. The interface has its own transaction delineators.
>  e.g. open/close, or begin/end.  These clearly define when the
>  transaction begins and ends, and there is no reason to suspect that
>  a component holds any resources after the close/end method is
>  called.  [Since I'm really only considerating the end of the
>  transaction only the close/end method is needed].  An example of
>  this would be a SAX Transformer with its startDocument/endDocument
>  methods, or a non-component example might be a java.io.InputStream
>  with its close method.
>
>  3. Finally there are interfaces which imply a transaction (i.e. that
>  the implementation may need to hold resources), but do not have any
>  methods delineating the transaction.  The only example I can think
>  of for this one is not a component but the java.util.Iterator, which
>  has a next() method but no ending method.
>
>(end quote)
>
>------------------
>TYPE 1:
>
>Components of type 1 are looked up directly:
>
>public class MyComposer implements Composable {
>
>    private DocumentStore store = null;
>
>    public void compose (ComponentManager manager) {
>        store = (DocumentStore) manager.lookup (DocumentStore.ROLE);
>    }
>}
>
>Components of type 1 are never released. A client keeps a reference
>to it for the duration of its lifetime.
>
>I believe we have concensus on this.
>
>------------------
>TYPES 2 and 3:
>
>Components of type two and three are not looked up directly:
>
>public class MyComposer implements Composable {
>
>    private TransformerManager transformerManager = null;
>
>    public void compose (ComponentManager manager) {
>        transformerManager = (TransformerManager) manager.lookup
>(TransformerManager.ROLE);
>    }
>
>    public void doStuff () {
>        Transformer transformer = transformerManager.getTransformer ();
>        try {
>        } finally {
>            transformerManager.release (transformer);
>            // OR
>            transformer.release(); 
>            // OR
>            transformer.endDocument();
>        }
>    }
>}
>

I'm assuming that TransformerManager is defined as a component and
declared as a dependent of MyComposer.  Operations relating to
release/endDocument etc. are non-lifecycle interfaces (i.e. there
are service interfaces declared by the TransformerManager component).

>
>
>As seen above, for components whose interface makes them thread-unsafe,
>

Is it interface, implementation, or meta that declares non-thread-safe ?
I'm presuming this would be handled with a service attribute at the 
meta-level.

>
>there *must* be a method, either in the associated manager, or in the
>component itself, that, when called by the client, indicates that
>the client is finished using the component.
>
>I believe we have concensus on this.
>
>(end summary)
>
>--------------------------------------------
>
>Implications of Type 1 (my own thoughts, no concensus on this):
>
> + As there is no release() or equivalent, 
>

Agreed.

>the implementation is
>   restricted to only holding resources during method invokations.
>

I agree in principal - but (a) this is one of those things you/I/we have 
no control over and (b) the term resource is open to interpritation. But 
this is neither here nor there...

>
>   
> + All implementations must be thread safe.
>

+1

>
>
>
>Implications of types 2 and 3 (my own thoughts, no concensus on this):
>
> + As there is a release() or equivalent, the implementation may
>   hold resources during the entire transaction.
>

+1

>
>   
> + Implementations may be thread safe, but need not be.
>

It's an implementation issue.

>
>
> + For components of this type selected with a hint, we still
>   get the ugly two-step lookup we have with ComponentSelectors.
>

Can you go into this further.  I'm right now loking at selection 
policies concerning the case where multiple component candidates are 
presented based on metainfo declarations.  I would really like to 
know/understand if this is a real runtime issues (i.e. the actual 
selection criteria is reflected in the request state of the component) 
or if this can be handeled at the type level.

>
>
> + A XXXXManager interface and a corresponding implementation is
>   needed for each type 2 and 3 component == more code to write.
>

Would the XXXXManager interface typically be something like the current 
CM interface or would it be more like the mpool.Pool interface ... or 
more typically something custom ?

Cheers, Steve.


-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message