Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4545FD01.90500@apache.org>
Date: Mon, 30 Oct 2006 14:24:17 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Using Avalon Components in Spring Components
References: <ei4j8l$1gk$1@sea.gmane.org> <4545DD34.4050402@apache.org>
 <ei4t8p$2qu$1@sea.gmane.org>
In-Reply-To: <ei4t8p$2qu$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Alexander Klimetschek wrote:
> Carsten Ziegeler schrieb:
>>> But roles are a different concept than bean-ids....
>> Why do you think so?
> 
> I am not a Spring expert, but roles have this inheritance concept, and 
> bean-ids are merely just IDs, aren't they?
> 
Ah, yes, the original idea of Avalon included the possibility that there
might be
several implementations for the same role and you can choose at runtime,
like we today have the Generator role with the different available
generator implementations.
Now, the old avalon way to handle this was to lookup a
component(service) selector for the role, and then the real component
from this selector by using a hint(which can be compared to a key).

While this approach is very natural, it has some drawbacks like for
example you have to know whether you're looking up directly a component
or through a component selector etc.

In the end with recent Avalon containers this has been simplified by
either using the role for the component id or, in the case of several
implementations, by using "{role}/{key}" as the component id. And this
is actually how it works today in 2.2 with Spring as well, so you could
connect to the file generator by "o.a.c.g.Generator/file".

HTH
Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/