avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Thu, 10 Jan 2002 15:51:46 GMT
Answer inline:

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, January 10, 2002 4:27 PM
> Leo Sutic wrote:
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> ...
> That is one implementation.  However, the contract of a ComponentManager
> is to match a lookup request to a Component--nothing more.

That is exactly like the contract for a Map... which uses an Object key!

> ...
> The ComponentManager is free to have a default component for any specific
> role.

And even to have its own component "indexing"/mapping strategy.

> > Since the Context may have, for example, HttpRequests, I
> > do not want to let the CM interpret the contents of it.
> That is up to you, but I think it might be an artificial limitation to the
> ComponentManager in general.

Me too. It is just another component "indexing"/mapping strategy.

> > BTW, do we dump the Component interface?
> I think that is the general consensus.  However I do have one more use for
> it:
> If we move the release() method from ComponentManager, and place it in the
> Component interface, then Components that require releasing because they
> are pooled have a mechanism to do so.  That policy should be 
> decided by the
> work interface.  For example: a component that extends 
> ContentHandler cannot
> be threadsafe, so it would implement the Component interface--but 
> a component
> that does not need to be pooled by virtue of the work interface would not
> implement the Component interface.
> This addresses the current need for the SingleThreaded and 
> Threadsafe marker
> interfaces.  In Cocoon parlance, the usage would be something like this:
> DataSourceComponent datasource =
>      (DataSourceComponent) manager.lookup( 
> DataSourceComponent.ROLE, this.context );
> Generator generator = (Generator) manager.lookup( Generator.ROLE, 
> this.context );
> // .... use both generator and DataSourceComponent ...
> // NOTE: Generator extends the Component interface and 
> DataSourceComponent does not
> generator.release();
> The enforcement would be that all Components are assumed to be 
> ThreadSafe in implementation,
> with the exception of those whose interfaces will not allow it.  
> In those cases, the
> Components will be pooled, and extend the Component interface 
> that will look like this:
> interface Component
> {
>      void release();
> }
> This approach simplifies the use of the Component infrastructure 
> tremendously as we no
> longer have to have big complex try/catch/finally methods to 
> ensure that we release
> all components even if they are ThreadSafe.
> Also by enforcing the lifestyle of the Components like this, we 
> encourage threadsafety
> as a system goal--which does increase the efficiency of using 
> system resources.
> Of course, we could address the whole issue by returning to the 
> concept that all Components
> must be ThreadSafe, and in the cases of a Transformer that 
> extends ContentHandler it would
> have to be changed like this:
> interface Transformer
> {
>      XMLFilter getFilter(Context context, String source, Parameters);
> }
> That way, the part of the interface that precluded the 
> Transformer from being ThreadSafe
> returns a unique instance to be used in the Pipeline.
> In the end, this may be the best option in all, and we would have 
> to beef up the Developing
> With Avalon paper even more to teach these principles.

That is a new contract. It would be confusing to use the same name.

But worse, then you make it harder again to use third party tools.

I think that a SingleThreaded interface marker can still have its 
use if you do not want to put this kind of info in a implementation
as I do and, instead, use a generic mechanism that checks for such 
marker. I think, however, that this is kind of an "implementation 

Have fun,
Paulo Gaspar


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

View raw message