> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> 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.
Mine too. (Fail-fast).
> > /**
> > * 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 ?
Cocoon selects based on HttpServletRequest. Sure, as the
request is a stream of characters coming in on a socket,
you can send that string on, but it is ugly ugly ugly.
> 2. If a hint value is required - could it be formalized into a typed
> structure that could be built by a generic kernel?
I do not think so. Hints are too tightly coupled to the
ComponentSelectors, and come in too many forms.
> >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.
Yes.
> Operations relating to release/endDocument etc. are
> non-lifecycle interfaces (i.e. there are service interfaces
> declared by the TransformerManager component).
Yes.
> >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.
I mean for interfaces that implies state. Such as a SAX transformer
component. You'd look it up and then get a ContentHandler interface.
Since the methods must be called in a certain order, the SAX
transformer component can not return the same transformer instance.
The thread-unsafety is not declared, but rather a property of the
way the client is supposed to interact with the component.
> > + 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.
Well, if we take the current CM interface and use selectors (CS):
ComponentSelector cs = (ComponentSelector) manager.lookup (Comp.ROLE +
"Selector")
Comp comp = (Comp) cs.select (hint);
comp.doStuff ();
cs.release (comp);
manager.release (cs);
Now, add a lookup(String,Object) to A4 CM interface:
Comp comp = (Comp) manager.lookup (Comp.ROLE, hint);
comp.doStuff ();
manager.release (cs);
Neater, right?
But with the factory approach we have now:
CompManager cmanager = (CompManager) manager.lookup (CompManager.ROLE,
hint)
comp = cmanager.getInstance ();
comp.doStuff ();
cmanager.release (comp);
> 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)
If do not completely follow you here.
> 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 ?
Leaving that open. See my email to Carsten of about an hour ago... I
foresee that it will be *very* similar to the current CM interface,
on the grounds that it makes the framework easier to use.
What we have done is basically exposed the ComponentHandlers of A4
ECM.
So as it stands now, we have increased flexibility, satisfied some
architectural issues, and I think we have a good migration path.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
