Return-Path: 
 <dev-return-101343-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 40831 invoked from network); 23 Feb 2009 10:53:01 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 23 Feb 2009 10:53:01 -0000
Received: (qmail 19500 invoked by uid 500); 23 Feb 2009 10:53:00 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 19420 invoked by uid 500); 23 Feb 2009 10:52:59 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 19411 invoked by uid 99); 23 Feb 2009 10:52:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Feb 2009 02:52:59 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [212.85.125.162] (HELO v007528.home.net.pl) (212.85.125.162)
    by apache.org (qpsmtpd/0.29) with SMTP; Mon, 23 Feb 2009 10:52:50 +0000
Received: from sj162.internetdsl.tpnet.pl (HELO ?192.168.1.20?)
 (lgawron.mobilebox@home@80.55.87.162)
  by m029.home.net.pl with SMTP; Mon, 23 Feb 2009 10:52:23 -0000
Message-ID: <49A27FE4.5080404@mobilebox.pl>
Date: Mon, 23 Feb 2009 11:52:20 +0100
From: Leszek Gawron <lgawron@mobilebox.pl>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Servlet service: polymorphism and connections
References: <gnmlk3$hit$1@ger.gmane.org> <499EFF66.3030906@tuffmail.com>
 <49A2639F.3030209@apache.org> <gntu5u$7sl$1@ger.gmane.org>
In-Reply-To: <gntu5u$7sl$1@ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org

Andreas Hartmann wrote:
> Hi Grzegorz, hi Reinhard,
> 
> thanks for your replies!
> 
> Reinhard Pötz schrieb:
>> Grzegorz Kossakowski wrote:
>>> Andreas Hartmann pisze:
> 
> […]
> 
>> Andreas, have a look at "bean-maps" which are provided by the Spring
>> Configurator. You could have your validators implement a particular
>> interface and then you can collect them by using a bean-map. The you can
>> implement a validator servlet-service that uses this bean-map and does
>> the validation. Of course the last step is only necessary if you need to
>> get access to the validator services by using the servlet protocol.
> 
> I found the documentation on bean maps and Grzegorz' blog entry, but I'm 
> not quite sure if I understand the concept correctly. At a first glance 
> it looks very similar to Avalon selectors.
> 
> E.g. if I instantiate two beans like this:
> 
>   <bean name="myproject.Service/foo" … />
>   <bean name="myproject.Service/bar" … />
> 
> Is this sufficient for accessing the beans via the bean map?
> 
>   <bean name="my-client-bean">
>     <property name="services">
>       <configurator:bean-map type="myproject.Service">
>     </property>
>   </bean>
> 
>   Service foo = (Service) services.get("foo")

the beans should be named :
<bean name="foo" … />
<bean name="bar" … />


the matching is done by type - no need to have it in bean name.

If you want to retain your naming and still query by "foo", do this:

<bean name="myproject.Service/foo" … />
<bean name="myproject.Service/bar" … />

<bean name="my-client-bean">
   <property name="services">
     <configurator:bean-map type="myproject.Service" strip-prefix="true">
   </property>
</bean>

> If this is correct, it would solve the problem of registering the beans 
> at runtime (IIUC this is the major purpose of the bean map?).

exactly

> For my understanding: Would this be equivalent to getting the bean 
> directly from the app context?
> 
>   Service foo = (…) context.getBean(Service.class.getName() + "/foo")

Yes with one big GOTCHA: your beans should be singletons. I'll leave the 
explanation why as an exercise :)

-- 
Leszek Gawron                         http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.