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: [Summary] Avalon 5 ComponentManager interface
Date Wed, 12 Jun 2002 13:02:44 GMT

> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de] 
> Leo Sutic wrote:
> Yes, this should work, but I don't see the real advantage of 
> it.
> Now, a component framework should make working with 
> components very easy. As a client (or Composer) I personally 
> don't want to care about ThreadSafe or not (that is in my 
> eyes one of the big advantages of the current 4.x 
> implementation, although there are some other problems...). 
> Now, if I want to lookup a component, I have to know if it is 
> ThreadSafe or not. If it is ThreadSafe I directly get the 
> component on lookup - if not, I get a "factory" and need a 
> second method call on this factory to get the real component.
> And I believe that the client a) should not care about this 
> implementation detail and b) in some cases even might not 
> know about it.

I agree completely.

In my summary, I define Type 1 and Type 2,3 components.

The Type 1 components are *always* thread safe. Always, always,
always. You *never* *ever* get a factory.

Types 2 and 3 may or may not be threadsafe -> you *always* get
a factory. If the impl is threadsafe you get a factory anyway!

Basically, the presence/absence of a factory is defined by the
component interface. So if you code against the interface,
you will *always* get it right. Just like now. The only difference is 
that you will lookup() the factories in compose() and then use them
instead of going to the ComponentManager.

The only restriction is that if you need a pooled implementation of
a type 1 interface, you need to provide your own pool.

I predict that I'll stick to types 2 and 3, as I need to be able to
swap threadsafe/pooled components in and out. I predict Stephen
and Peter will stick to type 1, as they prefer to deal with pooling
in other ways.


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