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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
