avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Thu, 10 Jan 2002 15:57:41 GMT


> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> Leo Sutic wrote:
> 
> That is one implementation.  However, the contract of a ComponentManager
> is to match a lookup request to a Component--nothing more.

Yes, but there must be some predictability here. The returned object
must be castable to the asked-for interface, and there must be some
standard way of configuring a component manager so that the configurator
can with reasonable confidence say that "this will map the lookup request X
to component Y."

You may want the CM to be a very general thing, to be able to handle lookups
of not just components, but of everything under the sun, but the less you specify
about its behavior the less useful it gets.

At the moment, the CM does one thing and does it very well - handles *components*.

If you need a general lookup class, try an Object DB.
 
> If a Servlet that uses Avalon wants to interpret the Context for the URI,
> and other properties, it is not up to us to limit that approach.  In fact,
> just such an approach would be very powerful.

But how would that be done if not via a ComponentSelector?
 
> The ComponentManager is free to have a default component for any specific
> role.
> 
> > 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.

Not really - whatever logic you want to use to interpret the Context in
the CM, I would move to a default ComponentSelector and then use as above. 
 
> > 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.

Then you make the user of a component have to keep track of whether
a component is thread safe or not, which is bad. Now, I can treat all
components as being just components, irrespective of whether they are
pooled or single threaded or threadsafe. While you will save 3-4 lines 
of code, I think this will result in a massive increase in coupling.

What if a previously pooled component by some magical way becomes
thread safe? With your proposal, that would be a backwards-incompatible
change.
 
> 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

No. Then we would end up with all components being factories.

> , 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,

Not by far.

/LS


--
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