You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/02/11 09:23:32 UTC
From a single Component to ComponentSelector
I have a question on the (current;) ComponenManager.
Right now I have a Component in our project which
can simply looked up by "cm.lookup(role)" but now
I'm about to need another Component for the same
role. So usually I would use a ComponentSelector
for this. But what happens with the current code
where I only do a lookup(role). Do I have to go
threw the code and change this to use the
ComponentSelector, too?
In the end it comes to one question: What's the
behaviour of the ComponentManager when a "lookup(role)"
is called when there are more than one Components
for that role?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: From a single Component to ComponentSelector
Posted by Mark Woon <mo...@SMI.Stanford.EDU>.
Torsten Curdt wrote:
> I have a question on the (current;) ComponenManager.
> Right now I have a Component in our project which
> can simply looked up by "cm.lookup(role)" but now
> I'm about to need another Component for the same
> role. So usually I would use a ComponentSelector
> for this. But what happens with the current code
> where I only do a lookup(role). Do I have to go
> threw the code and change this to use the
> ComponentSelector, too?
I'm sure others will correct me if I'm wrong, but I think it depends on how you
define your roles. If you currently had:
<role name="org.apache.avalon.excalibur.datasource.DataSourceComponent"
shorthand="datasource"
default-class="org.apache.avalon.excalibur.component.JdbcDataSource"/>
And you replaced it with;
<role name="org.apache.avalon.excalibur.datasource.DataSourceComponentSelector"
shorthand="datasources"
default-class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector">
<hint shorthand="jdbc"
class="org.apache.avalon.excalibur.datasource.JdbcDataSource"/>
<hint shorthand="j2ee"
class="org.apache.avalon.excalibur.datasource.J2eeDataSource"/>
</role>
You'll have to lookup the ComponentSelector before getting the actual
Component. However, if you have both entries, then you wouldn't have to change
any existing code, because the ComponentManager would still be able to find
your Component under it's original role. The bad thing is that you'd only have
access to one type of DataSourceComponent if you don't go through the
ComponentSelector.
-Mark
Re: From a single Component to ComponentSelector
Posted by Peter Donald <pe...@apache.org>.
On Mon, 11 Feb 2002 19:23, Torsten Curdt wrote:
> I have a question on the (current;) ComponenManager.
> Right now I have a Component in our project which
> can simply looked up by "cm.lookup(role)" but now
> I'm about to need another Component for the same
> role. So usually I would use a ComponentSelector
> for this. But what happens with the current code
> where I only do a lookup(role). Do I have to go
> threw the code and change this to use the
> ComponentSelector, too?
It really depends on how you want to do it. For instance there is an
alternative to using a ComponentSelector if you have a fixed number of
alternatives. For instance consider the case of a Mail server which has
access to 2 MailRepository components. The first one is for spooling (ie
temporary storage while being processed) and the second is for long term
storage.
Both components implement the same interface - namely MailRepository - but
they are different roles because one is intended to be used as a spool while
the other is intended to be used for long term storage. So I would store them
flatly in the ComponentManager as
MailRepository.ROLE --> LongTermMailRepository object
MailRepository.ROLE + "/Spool" --> ShortTermSpoolMailRepository object
> In the end it comes to one question: What's the
> behaviour of the ComponentManager when a "lookup(role)"
> is called when there are more than one Components
> for that role?
The default ComponentManager would only return the component last added under
the specific role.
--
Cheers,
Pete
*--------------------------------------------------*
| Wise men don't need advice. Fools don't take it. |
| -Benjamin Franklin |
*--------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: From a single Component to ComponentSelector
Posted by Torsten Curdt <tc...@dff.st>.
Berin Loritsch wrote:
> Torsten Curdt wrote:
>
>> I have a question on the (current;) ComponenManager.
>> Right now I have a Component in our project which
>> can simply looked up by "cm.lookup(role)" but now
>> I'm about to need another Component for the same
>> role. So usually I would use a ComponentSelector
>> for this. But what happens with the current code
>> where I only do a lookup(role). Do I have to go
>> threw the code and change this to use the
>> ComponentSelector, too?
>>
>> In the end it comes to one question: What's the
>> behaviour of the ComponentManager when a "lookup(role)"
>> is called when there are more than one Components
>> for that role?
>> --
>> Torsten
>
>
>
> It depends on how you set up your environment. One of
> the reasons that I claimed one of the helpful idioms was
> to add the word "Selector" to the role name, is so you can
> handle things like this.
>
> I.e.
>
> DataSourceComponent.ROLE ->
> JdbcDataSource(jdbc:oracle:thin:BORG:1521:borg)
> DataSourceComponent.ROLE + "Selector" -> ComponentSelector
>
> Do you see where I am going? The Selector has a unique mapping,
> allowing the
> rest of the system to migrate eventually (or even not at all).
>
> This gives you the flexibility of default Components for the Selector
> without
> having to go through the Selector level.
>
>
Ahh... so for migration purposes I could have two different roles for the
same Component. I'm wondering couldn't this be problem? I am thinking of the
SingleThreaded interface e.g. - not the case here so I am fine ;)
...but in general
Anyway thanks!
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: From a single Component to ComponentSelector
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
> I have a question on the (current;) ComponenManager.
> Right now I have a Component in our project which
> can simply looked up by "cm.lookup(role)" but now
> I'm about to need another Component for the same
> role. So usually I would use a ComponentSelector
> for this. But what happens with the current code
> where I only do a lookup(role). Do I have to go
> threw the code and change this to use the
> ComponentSelector, too?
>
> In the end it comes to one question: What's the
> behaviour of the ComponentManager when a "lookup(role)"
> is called when there are more than one Components
> for that role?
> --
> Torsten
It depends on how you set up your environment. One of
the reasons that I claimed one of the helpful idioms was
to add the word "Selector" to the role name, is so you can
handle things like this.
I.e.
DataSourceComponent.ROLE -> JdbcDataSource(jdbc:oracle:thin:BORG:1521:borg)
DataSourceComponent.ROLE + "Selector" -> ComponentSelector
Do you see where I am going? The Selector has a unique mapping, allowing the
rest of the system to migrate eventually (or even not at all).
This gives you the flexibility of default Components for the Selector without
having to go through the Selector level.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: From a single Component to ComponentSelector
Posted by Michael McKibben <mi...@hihat.net>.
Hello, I think I can answer your question... When looking up a Component
from the ExcaliburComponentManager, it is always a one-one mapping. The
ComponentSelector is just another type of Component! Normally the
ComponentSelector is bound under the name Component.ROLE + "Selector", so
your code does not necessarily have to change. For example, you could bind a
default implementation under Component.ROLE, and your new code can lookup
the ComponentSelector under Component.ROLE + "Selector" and select an
appropriate implementation (Of course, this will mean that you have an extra
component lying around just for legacy code.)
Another alternative would be to write a custom ComponentManager and override
the behavior of lookup(). In the case where nothing is bound under
Component.ROLE it would check to see if a ComponentSelector is bound under
the name Component.ROLE + "Selector". If so, it would then select a
"default" implementation and return that. Your ComponentManager would have
to somehow know which hint is the default, perhaps by the configuration.
E.g.
<component
class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector"
role="MyComponentSelector" default-hint="default">
<component-instance name="default" class="MyDefaultImpl"/>
</component>
Regards,
--mike
-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@dff.st]
Sent: Monday, February 11, 2002 1:24 AM
To: Avalon Developers List
Subject: From a single Component to ComponentSelector
I have a question on the (current;) ComponenManager.
Right now I have a Component in our project which
can simply looked up by "cm.lookup(role)" but now
I'm about to need another Component for the same
role. So usually I would use a ComponentSelector
for this. But what happens with the current code
where I only do a lookup(role). Do I have to go
threw the code and change this to use the
ComponentSelector, too?
In the end it comes to one question: What's the
behaviour of the ComponentManager when a "lookup(role)"
is called when there are more than one Components
for that role?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>