You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/04/09 10:53:27 UTC
[RT] New Lookup mechanism
After looking at several container frameworks, I think we should
add a new lookup mechanism to the Avalon Framework.
I know this issue has been discussed before several times, but why
not doing it again after some years inbetween?
Now with ECM and Fortress a Service (Interface) declares in most cases
a constant ROLE, like this:
public interface MyService {
String ROLE = MyService.class.getName();
...
}
I don't know how this is done with Merlin.
Anyways, the lookup is then done using this constant:
MyComponent c = (MyComponent)this.serviceManager.lookup( MyService.ROLE );
or
MyComponent c = (MyComponent)this.serviceManager.lookup( MyService.ROLE +
'/' + hint );
There is never a lookup that uses some custom role name, like
lookup("my-parser"); I think such lookups with custom role names
should not be used anyway as they are way too error-prone.
And even worse, ECM has the ugly concept of Selectors, so you first
lookup a selector using MyService.ROLE+"Selector" and then the
component from the selector using the hint. With the following semantics
you combine the two in one interface.
Now, what do you think of using an easier solution:
public interface Locator {
Object lookup(Class clazz, String hint); // or Object hint
}
With this interface, you don't need the ROLE constant anymore and the
container can check the type of the returned object avoiding class cast
exceptions. And you can see directly in your code which type is returned
by the lookup. (Creating proxies is also a little bit easier as the lookup
method knows which interface to proxy without having the need to get
this information from somewhere else).
This approach is also used by other container frameworks and imho it gives
the lookup method more meaning and reduces errors because of typos.
So, I propose to add a new interface with this lookup semantics to avalon
framework
with a corresponding IoC interface to give this locator to components.
The default implementation for all containers at avalon could be that
a lookup(Class clazz, String hint) is "converted" to a
serviceManager.lookup(clazz.getName()) if hint is null or
serviceManager.lookup(clazz.getName() + '/' + hint) otherwise.
WDYT?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 14 April 2004 00:25, Stephen McConnell wrote:
> 1. the interface we use for locating something (lets call
> it Locator for the purpose of discussion)
Not very important right now.
> 2. the interface used to supply and instance of a Locator
> to a component
Not very important right now.
> 3. the sort of information that a component can include
> in a locate request and the expected behavior of
> container in resolving such a request
> public void someDeliveryMethod( Locator locator )
> {
> Map map = new Hashtable();
> map.put( "color", "red" );
> Football football = locator.locate( Football.class, map );
> }
Suddenly in the land of "Query Languages" :o)
> Possible interpretations:
>
> 1. color is an attribute of a component type
> 2. colour is an attribute of a service implemented by a
> a component type
> 3. color is a feature attributed to a component model
> (i.e. component model x has configuration y and is
> tagged with attribute color=red)
> 4. color is an attribute used by a selection handler
> that knows about the Football class
This shows that the previous assessment that the "hint" and other semantics
were flawed, and needs rectification.
Nevertheless, if 'color' is understood by the Locator and the Locator is
'associated' or 'configured' with the Service and/or component(s), then we
are more into a "Custom Context" type of reasoning.
But then again, for Merlin in the current shape, you can do;
public void service( ServiceManager sm )
{
FootballLocator fbl = (FootballLocator) sm.lookup( "mylocator" );
Football ball = fbl.getBallByColor( "red" );
:
:
}
by making the FootballLocator a Facility, which query the model in whatever
way necessary.
And then technically one could do "Custom Locators" either via "Method
Injection" or "Constructor Injection", like;
public void service( FootballLocator locator )
{
Football ball = locator.getBallByColor( "red" );
}
or
public MyComponent( FootballLocator locator )
{
Football ball = locator.getBallByColor( "red" );
}
I don't know what I think. I still want to hear about more real use-cases to
see what people are really looking for.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> Sent: Thursday, April 15, 2004 4:31 PM
> To: Avalon Developers List
> Subject: Re: [RT] New Lookup mechanism
>
> Hi Alex
>
> > So these Entry attributes here are used
> > as the criteria to query for a specific service?
>
> Basically, an entry could be a String. However, making it an interface
> allows it to grow to cover the ever growing ways of defining attributes.
Makes sense it's like a JNDI context.
> In a static world, the client code knows exactly what to ask and thus
> knowing a key, say an ID, suffices.
>
> In a dynamic world, as in Web Services / Jini, the client is interested in
> a
> give Service based on given criteria. Just the way you would lookup in
> Yello Pages to find a Plumber, a client code could lookup for one or
> several
> interesting services based on certain criteria. The criteria could be
> very
> different for different clients.
Oh I agree with you here whole heartedly.
> Some interesting criteria in a binary world (like Java/Jini) as opposed to
> a
> textual world (like XML/Web services)
> 1. ID: ID is always an interesting key. If you knew exactly which plumber
> to lookup for, it would make it very easy
Yep makes sense and this is what we do with the ServiceManager today.
We look up by id. Some seem to confuse the situation a bit by using
the name of the interface as the key (ROLE). Ideas seemed to be mixed
up all over the place. The concept of just calling it a darn id, a
primary key if you will is just simple and the case. Don't know why
we just have not done that.
> 2. Class(es): The client is probably most interested in Interface(s) a
> certain service implements. In few cases, the client could be interested
> in
> the implementation classes, but this would be rare. When you lookup in
> Yellow Pages, you are probably interested in looking up for plumbers, also
> Plumber interface.
I think this is the portion that explains to Hammet what you're
referring to: a reference to the service interface and not a
implementation class. Unfortunately that gets mixed up in terminology
because an Interface is a class in Java but I understand what you mean.
I think Hammet thought you were referring to the actual implementation
Class.
Referring to the service interface is just fine by me - how else would
you loosely express the characteristics of the service in Java?
> 3. Entry: Attributes are very interesting when the client code needs to
> filter the results of a lookup. You would probably like to lookup for
> plumbers in your neighbourhood that are cheap!
>
> Under controlled environments, like a business application, the client
> code
> knows exactly what to lookup. Therefore, the result of a query is a
> single
> service. However, in dynamic systems, say an agent system, the result
> would
> probably be several services. In such situations, the client code needs
> to
> handle the result and peak the most appropriate result, also the burden is
> on the client code.
Yes this is the most interesting. Actually because of my efforts on
the directory side I've been thinking a lot about this. The lookup of
services fit hand in hand with directories. I think that a UDDI
scheme exists for LDAP already so people are seeing LDAP as a read
optimized backend for looking up these Web service. We could do the
same and use the search capabilities of the directory and its hierarchy
to nicely model components and their relationships.
> In a large system, there could be several Registrars. Registrars could
> announce their services to each other and create a network of registrars.
> This could be very interesting in Merlin, as each underlying container
> could
> own its own registrar. Further, the underlying registrar could ask the
> registrar in the parent or neigbouring container if it needs to.
Ahh LDAP referrals work very nicely in enabling such a system of
registrars.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Nader Aeinehchi <na...@aeinehchi.com>.
Hi Alex
> So these Entry attributes here are used
> as the criteria to query for a specific service?
Basically, an entry could be a String. However, making it an interface
allows it to grow to cover the ever growing ways of defining attributes.
In a static world, the client code knows exactly what to ask and thus
knowing a key, say an ID, suffices.
In a dynamic world, as in Web Services / Jini, the client is interested in a
give Service based on given criteria. Just the way you would lookup in
Yello Pages to find a Plumber, a client code could lookup for one or several
interesting services based on certain criteria. The criteria could be very
different for different clients.
Some interesting criteria in a binary world (like Java/Jini) as opposed to a
textual world (like XML/Web services)
1. ID: ID is always an interesting key. If you knew exactly which plumber
to lookup for, it would make it very easy
2. Class(es): The client is probably most interested in Interface(s) a
certain service implements. In few cases, the client could be interested in
the implementation classes, but this would be rare. When you lookup in
Yellow Pages, you are probably interested in looking up for plumbers, also
Plumber interface.
3. Entry: Attributes are very interesting when the client code needs to
filter the results of a lookup. You would probably like to lookup for
plumbers in your neighbourhood that are cheap!
Under controlled environments, like a business application, the client code
knows exactly what to lookup. Therefore, the result of a query is a single
service. However, in dynamic systems, say an agent system, the result would
probably be several services. In such situations, the client code needs to
handle the result and peak the most appropriate result, also the burden is
on the client code.
In a large system, there could be several Registrars. Registrars could
announce their services to each other and create a network of registrars.
This could be very interesting in Merlin, as each underlying container could
own its own registrar. Further, the underlying registrar could ask the
registrar in the parent or neigbouring container if it needs to.
Finally, in our project, we a made it easy for the developers to use the
Registrar simply by providing a couple of utility classes.
Best Regards
--
Nader Aeinehchi
Aasenhagen 66 E
2020 Skedsmokorset
NORWAY
Direct and Mobile +47 41 44 29 57
Tel (private): +47 64 83 09 08
Fax +47 64 83 08 07
www.aeinehchi.com
----- Original Message -----
From: "Alex Karasulu" <ao...@bellsouth.net>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Thursday, April 15, 2004 9:27 PM
Subject: RE: [RT] New Lookup mechanism
> Nader,
>
> > -----Original Message-----
> > From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> > Sent: Thursday, April 15, 2004 3:06 PM
> > To: Avalon Developers List
> > Subject: Re: [RT] New Lookup mechanism
>
>
> > 4. A client code looks up for a particular service by sending Template.
> > Template may include a combination of Id, Class(es) and Entry(ies)
> >
> > public class Template implements Serializable {
> > public Id id;
> > public Class[] classes;
> > public Entry[] attributes;
> > public Template(Id id, Class[] classes, Entry[] attributes)
> > }
>
> Very interesting mechanism Nader! So these Entry attributes here are used
> as the criteria to query for a specific service? I like this very much
> because it seems simple yet very expressive.
>
> I wonder what others will think about it. BTW I need to start
> getting educated on JINI. Have not really taken a look at it but
> we at Avalon should be looking at other mechanisms before we invent
> our own.
>
> Alex
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Alex Karasulu <ao...@bellsouth.net>.
Nader,
> -----Original Message-----
> From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> Sent: Thursday, April 15, 2004 3:06 PM
> To: Avalon Developers List
> Subject: Re: [RT] New Lookup mechanism
> 4. A client code looks up for a particular service by sending Template.
> Template may include a combination of Id, Class(es) and Entry(ies)
>
> public class Template implements Serializable {
> public Id id;
> public Class[] classes;
> public Entry[] attributes;
> public Template(Id id, Class[] classes, Entry[] attributes)
> }
Very interesting mechanism Nader! So these Entry attributes here are used
as the criteria to query for a specific service? I like this very much
because it seems simple yet very expressive.
I wonder what others will think about it. BTW I need to start
getting educated on JINI. Have not really taken a look at it but
we at Avalon should be looking at other mechanisms before we invent
our own.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Nader Aeinehchi <na...@aeinehchi.com>.
Hello
Please allow me to engage myself in the discussion of Lookup mechanism and
make a suggestion based on a customer project we did.
1. Inspired by Jini, we developed a Registrar. Registrar serves the its
service providers and service consumers.
We tried to keep the interface of Registrar as much as possible as Jini
Registrar such that we could switch to Jini in future. However, we did not
develop the leasing mechanism of Jini.
2. The interface of Registrar:
public interface Registrar {
Item register(Item item );
void unregister(Item item );
Object lookup(Template tmpl);
Id getId();
}
3. The item encapsulates a service plus attributes.
Attributes may be for example, group, container etc:
public class Item implements Serializable {
public Id id;
public Object service;
public Entry[] attributes;
public Item(Id id, Object service, Entry[] attributes)
}
4. A client code looks up for a particular service by sending Template.
Template may include a combination of Id, Class(es) and Entry(ies)
public class Template implements Serializable {
public Id id;
public Class[] classes;
public Entry[] attributes;
public Template(Id id, Class[] classes, Entry[] attributes)
}
5. The above model provide us a very flexible Registrar. Furthermore, we
made sure that Registrar was NOT singleton such that a group of components
(say in a particular container) could establish an own Registrar.
6. The implementation was few hundred lines of code.
7. We achieved a reactive self-healing system using three components:
Registrar, Hub and Spoke Event system and an Exception Manager. Our
Exception Manager could run a Repair Command class for a corresponding
Exception. But that is another story...........
Best Regards
--
Nader Aeinehchi
Aasenhagen 66 E
2020 Skedsmokorset
NORWAY
Direct and Mobile +47 41 44 29 57
Tel (private): +47 64 83 09 08
Fax +47 64 83 08 07
www.aeinehchi.com
----- Original Message -----
From: "Bruno Dumon" <br...@outerthought.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Wednesday, April 14, 2004 7:44 PM
Subject: Re: [RT] New Lookup mechanism
> On Tue, 2004-04-13 at 18:25, Stephen McConnell wrote:
> > Hi Marcus!
> >
> > I've got some general questions about selection that perhaps you or
> > other could fill me in on. First off - I'm separating out in my head
> > three different things:
> >
> > 1. the interface we use for locating something (lets call
> > it Locator for the purpose of discussion)
> > 2. the interface used to supply and instance of a Locator
> > to a component
> > 3. the sort of information that a component can include
> > in a locate request and the expected behavior of
> > container in resolving such a request
> >
> > Item (3) is the thing that IMO needs to be expanded on. Here is a
> > couple of examples of an invocation followed by a couple of questions.
> > Please not that I'm also not really worried about the argument or
> > signatures just yet - so don't pay any attention to the approach - I'm
> > in information gathering stage!
> >
> > public void someDeliveryMethod( Locator locator )
> > {
> > Map map = new Hashtable();
> > map.put( "color", "red" );
> > Football football = locator.locate( Football.class, map );
> > }
> >
> > In the above the component implementation has to assume that a container
> > has been configured such that "color" is understood - i.e. is
> > translatable to something that will help in the determination of the
> > appropriate instance to be returned.
> >
> > Possible interpretations:
> >
> > 1. color is an attribute of a component type
> > 2. colour is an attribute of a service implemented by a
> > a component type
>
> isn't the service already identified uniquely by the interface?
>
> > 3. color is a feature attributed to a component model
> > (i.e. component model x has configuration y and is
> > tagged with attribute color=red)
>
> yes
>
> I think this also comes closest to what selectors offer, which allow the
> same implementation class with different configurations to be assigned
> different (excuse the word) hints.
>
> > 4. color is an attribute used by a selection handler
> > that knows about the Football class
>
> Maybe, but this requires extra work.
>
> >
> > Some questions:
> >
> > 1. if color is understood by a container, but no solution
> > are resolvable - is that a failure or is the container
> > obliged to return at least some football
>
> failure
>
> >
> > 2. which leads to the question .. should we be describing
> > a Query object instead of a map? E.g.
> >
> > Constraint color = new Constraint( "color" );
> > color.setRequired();
> > color.setValue( "red" );
> > locator.locate( Football.class, new Query[]{ color } );
>
> don't know.
>
> As Carsten pointed out, it might well be that a simple key assigned to a
> component model is all we need. Until know, I haven't encountered the
> need for more complex queries yet (but also hadn't thought about the
> possibility).
>
> --
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org bruno@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-13 at 18:25, Stephen McConnell wrote:
> Hi Marcus!
>
> I've got some general questions about selection that perhaps you or
> other could fill me in on. First off - I'm separating out in my head
> three different things:
>
> 1. the interface we use for locating something (lets call
> it Locator for the purpose of discussion)
> 2. the interface used to supply and instance of a Locator
> to a component
> 3. the sort of information that a component can include
> in a locate request and the expected behavior of
> container in resolving such a request
>
> Item (3) is the thing that IMO needs to be expanded on. Here is a
> couple of examples of an invocation followed by a couple of questions.
> Please not that I'm also not really worried about the argument or
> signatures just yet - so don't pay any attention to the approach - I'm
> in information gathering stage!
>
> public void someDeliveryMethod( Locator locator )
> {
> Map map = new Hashtable();
> map.put( "color", "red" );
> Football football = locator.locate( Football.class, map );
> }
>
> In the above the component implementation has to assume that a container
> has been configured such that "color" is understood - i.e. is
> translatable to something that will help in the determination of the
> appropriate instance to be returned.
>
> Possible interpretations:
>
> 1. color is an attribute of a component type
> 2. colour is an attribute of a service implemented by a
> a component type
isn't the service already identified uniquely by the interface?
> 3. color is a feature attributed to a component model
> (i.e. component model x has configuration y and is
> tagged with attribute color=red)
yes
I think this also comes closest to what selectors offer, which allow the
same implementation class with different configurations to be assigned
different (excuse the word) hints.
> 4. color is an attribute used by a selection handler
> that knows about the Football class
Maybe, but this requires extra work.
>
> Some questions:
>
> 1. if color is understood by a container, but no solution
> are resolvable - is that a failure or is the container
> obliged to return at least some football
failure
>
> 2. which leads to the question .. should we be describing
> a Query object instead of a map? E.g.
>
> Constraint color = new Constraint( "color" );
> color.setRequired();
> color.setValue( "red" );
> locator.locate( Football.class, new Query[]{ color } );
don't know.
As Carsten pointed out, it might well be that a simple key assigned to a
component model is all we need. Until know, I haven't encountered the
need for more complex queries yet (but also hadn't thought about the
possibility).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 15 April 2004 01:26, Stephen McConnell wrote:
> <component name="football-thing" class="MyOrdinaryComponent">
+---------^^^^^^^^^^^^^^
|
SportsShop ---+
Right?
:o)
I love this example!!
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-04-14 at 19:26, Stephen McConnell wrote:
> Bruno Dumon wrote:
>
> > On Wed, 2004-04-14 at 09:59, Niclas Hedhman wrote:
> >
> >>On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
> >>
> >>
> >>>This key should be a simple string,
> >>>so the above could read:
> >>>locator.locate(Football.class, "red");
> >>
> >>Forgive me for a naive question;
> >>
> >>What is the difference of the above, from;
> >>
> >>servicemanager.lookup( "red-football" );
> >>or
> >>servicemanager.lookup( "/footballs/red" );
> >>
> >>Or in the case you need someone else to figure it out;
> >>
> >>FootballLocator fbl = (FootballLocator) sm.lookup( "footballs" );
> >>Football ball = fbl.locate( "red" );
> >>
> >>and the
> >>
> >>public class MyOrdinaryComponent
> >> implements FootballLocator
> >>{
> >> private ServiceManager sm;
> >>
> >> public Football locate( String color )
> >> {
> >> if( color.equals( "red" ) )
> >> return (Football) sm.lookup( "red-ball" );
> >> if( color.equals( "blue" ) )
> >> return (Football) sm.lookup( "blue-ball" );
> >> if( color.equals( "green" ) )
> >> return (Football) sm.lookup( "green-ball" );
> >> return (Football) sm.lookup( "gray-ball" );
> >> }
> >>}
> >
> >
> > Is what you wrote above something that works today in Merlin? I thought
> > the argument supplied to sm.lookup is the name of a dependency, and that
> > you can only be dependent on one implementation of Football?
>
> The above code is a little incomplete - here is a full version:
>
> public class MyOrdinaryComponent
> implements FootballLocator
> {
> private ServiceManager sm;
>
> /**
> * @avalon.dependency type=Football" key="red-ball";
> * @avalon.dependency type=Football" key="blue-ball";
> * @avalon.dependency type=Football" key="green-ball";
> */
> public MyOrdinaryComponent( ServiceManager manager )
> {
> sm = manager;
> }
>
> public Football locate( String color )
> {
> if( color.equals( "red" ) )
> return (Football) sm.lookup( "red-ball" );
> if( color.equals( "blue" ) )
> return (Football) sm.lookup( "blue-ball" );
> if( color.equals( "green" ) )
> return (Football) sm.lookup( "green-ball" );
> return (Football) sm.lookup( "gray-ball" );
> }
> }
>
> Given the above merlin will happly associate instances of Football
> against the respective lookup keys. On the container side you can setup
> directives that control which components get assigned to respective keys.
>
> For example:
>
> <container name="demo">
>
> <component name="red-football" class="StandardFootball">
> <configuration>red-color</configuration>
> </component>
>
> <component name="blue-football" class="StandardFootball">
> <configuration>blue-color</configuration>
> </component>
>
> <component name="green-football" class="StandardFootball">
> <configuration>green-color</configuration>
> </component>
>
> <component name="football-thing" class="MyOrdinaryComponent">
> <dependencies>
> <dependency key="red-ball" source="red-football"/>
> <dependency key="blue-ball" source="blue-football"/>
> <dependency key="green-ball" source="green-football"/>
> </dependencies>
> </component>
>
> </container>
Ah, I hadn't looked yet into manual dependency resolution, didn't know
this was possible. Still, since this requires the FootballLocator to
know about the available implementations on beforehand, this doesn't fit
my needs.
>
> Alternatively - if MyOrdinaryComponent had a dependency on a finder
> facility, it could do this automatically based on matching features
> (providing we expose selection semantics in the model and update finder
> to enable this sort of query functionality).
yep.
Thanks for the info.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Stephen McConnell <mc...@apache.org>.
Bruno Dumon wrote:
> On Wed, 2004-04-14 at 09:59, Niclas Hedhman wrote:
>
>>On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
>>
>>
>>>This key should be a simple string,
>>>so the above could read:
>>>locator.locate(Football.class, "red");
>>
>>Forgive me for a naive question;
>>
>>What is the difference of the above, from;
>>
>>servicemanager.lookup( "red-football" );
>>or
>>servicemanager.lookup( "/footballs/red" );
>>
>>Or in the case you need someone else to figure it out;
>>
>>FootballLocator fbl = (FootballLocator) sm.lookup( "footballs" );
>>Football ball = fbl.locate( "red" );
>>
>>and the
>>
>>public class MyOrdinaryComponent
>> implements FootballLocator
>>{
>> private ServiceManager sm;
>>
>> public Football locate( String color )
>> {
>> if( color.equals( "red" ) )
>> return (Football) sm.lookup( "red-ball" );
>> if( color.equals( "blue" ) )
>> return (Football) sm.lookup( "blue-ball" );
>> if( color.equals( "green" ) )
>> return (Football) sm.lookup( "green-ball" );
>> return (Football) sm.lookup( "gray-ball" );
>> }
>>}
>
>
> Is what you wrote above something that works today in Merlin? I thought
> the argument supplied to sm.lookup is the name of a dependency, and that
> you can only be dependent on one implementation of Football?
The above code is a little incomplete - here is a full version:
public class MyOrdinaryComponent
implements FootballLocator
{
private ServiceManager sm;
/**
* @avalon.dependency type=Football" key="red-ball";
* @avalon.dependency type=Football" key="blue-ball";
* @avalon.dependency type=Football" key="green-ball";
*/
public MyOrdinaryComponent( ServiceManager manager )
{
sm = manager;
}
public Football locate( String color )
{
if( color.equals( "red" ) )
return (Football) sm.lookup( "red-ball" );
if( color.equals( "blue" ) )
return (Football) sm.lookup( "blue-ball" );
if( color.equals( "green" ) )
return (Football) sm.lookup( "green-ball" );
return (Football) sm.lookup( "gray-ball" );
}
}
Given the above merlin will happly associate instances of Football
against the respective lookup keys. On the container side you can setup
directives that control which components get assigned to respective keys.
For example:
<container name="demo">
<component name="red-football" class="StandardFootball">
<configuration>red-color</configuration>
</component>
<component name="blue-football" class="StandardFootball">
<configuration>blue-color</configuration>
</component>
<component name="green-football" class="StandardFootball">
<configuration>green-color</configuration>
</component>
<component name="football-thing" class="MyOrdinaryComponent">
<dependencies>
<dependency key="red-ball" source="red-football"/>
<dependency key="blue-ball" source="blue-football"/>
<dependency key="green-ball" source="green-football"/>
</dependencies>
</component>
</container>
Alternatively - if MyOrdinaryComponent had a dependency on a finder
facility, it could do this automatically based on matching features
(providing we expose selection semantics in the model and update finder
to enable this sort of query functionality).
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-04-14 at 09:59, Niclas Hedhman wrote:
> On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
>
> > This key should be a simple string,
> > so the above could read:
> > locator.locate(Football.class, "red");
>
> Forgive me for a naive question;
>
> What is the difference of the above, from;
>
> servicemanager.lookup( "red-football" );
> or
> servicemanager.lookup( "/footballs/red" );
>
> Or in the case you need someone else to figure it out;
>
> FootballLocator fbl = (FootballLocator) sm.lookup( "footballs" );
> Football ball = fbl.locate( "red" );
>
> and the
>
> public class MyOrdinaryComponent
> implements FootballLocator
> {
> private ServiceManager sm;
>
> public Football locate( String color )
> {
> if( color.equals( "red" ) )
> return (Football) sm.lookup( "red-ball" );
> if( color.equals( "blue" ) )
> return (Football) sm.lookup( "blue-ball" );
> if( color.equals( "green" ) )
> return (Football) sm.lookup( "green-ball" );
> return (Football) sm.lookup( "gray-ball" );
> }
> }
Is what you wrote above something that works today in Merlin? I thought
the argument supplied to sm.lookup is the name of a dependency, and that
you can only be dependent on one implementation of Football?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Noel J. Bergman wrote:
>
>
> > So, the first step we could take now, is to agree that this
> approach
> > "locate(Football.class)" is more elegant than
> > "lookup('org.hedhman.niclas.sports.Football')".
>
> I need to point out that the first of the two can be very
> important in some class loading environments. It ensures
> that the class is the one from the client's context, which
> may not be the same as the container's.
>
Ah, yes, very good point, I totally forgot that! Thanks!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by "Noel J. Bergman" <no...@devtech.com>.
> but imagine you write:
> sm.lookup( org.hedhman.niclas.sports.FootballLocator.class );
> (I left out the key for this example)
I did a grep of the entire dev@avalon mailing list archives. As far as I
can see, there has always been a lot of discussion of
lookup(aClassDescriptor) in various forms, but only one proposal to pass
both the expected/desired interface, and a key describing which of possibly
multiple such objects is desired:
The reason I have advocated passing the return class as a
parameter of the lookup/get call,
e.g., T t = (T) myContext.get(myKey, T.class)
is that the context can verify the type of object that the
caller is expecting. If we added a suitable throws clause
to that get method signature, we force the caller to prepare
for the exception.
That was in November, 2002.
> > Merlin will ensure that the returned type in the above is a
> > FootballLocator and nothing else - guaranteed.
> Yes, Merlin, but I'm talking about framework :)
In other words, why not use lookup(which-object, what-type)? Good question.
> So, the first step we could take now, is to agree that this approach
> "locate(Football.class)" is more elegant than
> "lookup('org.hedhman.niclas.sports.Football')".
I need to point out that the first of the two can be very important in some
class loading environments. It ensures that the class is the one from the
client's context, which may not be the same as the container's.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Niclas Hedhman wrote:
>
> On Wednesday 14 April 2004 17:05, Carsten Ziegeler wrote:
>
> > How do you know what service "red-football" returns? (Ok, of course
> > *you* know it), but anyone else seeing the above lookup
> might not know
> > it.
>
> Well, I am Merlin-user, and I think its solution is fairly elegant;
>
> /**
> * @avalon.dependency key="locator"
> * type="org.hedhman.niclas.sports.FootballLocator"
> */
> public void service( ServiceManager sm ) {
> FootballLocator fbl = (FootballLocator) sm.lookup( "locator" );
> :
> }
>
Yes, living as a Merlin user is easy :) Seriously, I know this solution
in Merlin, but I'm talking about the framework that doesn't know
anything about meta information.
Although this gets a little bit off-topic, but imagine you write:
public void service( ServiceManager sm ) {
FootballLocator fbl = (FootballLocator)
sm.lookup( org.hedhman.niclas.sports.FootballLocator.class );
}
(I left out the key for this example), you wouldn't need to declare
the meta info @avalon.dependency anymore. By looking at the code
of the service method the dependency is obvious.
</END OT>
> <snip content="ROLE elaboration" reason="agree" />
>
> > In addition by passing in the interface class, the
> container can check
> > if the correct component (implementing the interface) is
> returned etc.
>
> Merlin will ensure that the returned type in the above is a
> FootballLocator and nothing else - guaranteed.
Yes, Merlin, but I'm talking about framework :)
>
> > > FootballLocator fbl = (FootballLocator) sm.lookup(
> "footballs" );
> > > Football ball = fbl.locate( "red" );
> >
> > Yes, we already have this approach by using
> ServiceSelectors which is
> > way to complicated and leads to ugly rather ugly code.
>
> Ugly? :o) Two lines instead of one? Or is it related to
> try{}catch{} stuff?
>
Two lines and especially the try catch stuff. In some cases
you have to store the selector somewhere just in order to be
able to release the component later on properly etc.
> > > I think I don't understand where the Framework needs to
> be involved,
> > > and that is what I am trying to understand...
> >
> > You can do everything already today without any problems, using
> > ServiceSelectors etc. But imho these approaches are not
> elegant and in
> > no way standardized. Introducing this new locator is a concrete and
> > clear way.
>
> Ok. ServiceSelectors are somewhat different, and that
> difference is the reason why they are (and will remain) deprecated.
>
> I think you are bringing up 2 issues;
>
> 1. Use Class as Type, and enforce its use in Framework.
Yes.
> 2. Passing of auxillary selection information to the container.
Yes.
>
> I also assume that you are looking for a way so that for each
> Type, one can define a LocatorHandler (didn't want to use the
> word Selector, but in principle same thing)...
No :) The container doing this, based on the hint is enough for me.
>
> How about something like this?
>
> If the component declare a method "someFunkyName()" which
> takes a single argument which is a subinterface of "Locator",
> the container is responsible to provide an implementation of
> such Locator type to the component.
>
> public class MyComponent
> {
>
> public void locatorService( FootballLocator fbl )
> {
> Football ball = fbl.locate( "red" );
> }
> }
>
> Looks very easy for the component author.
> Do you think that would that be of help?
No, as I don't need a locator (Sorry) and I think this falls into
the category of "too much magic".
>
> I am fishing around the bush, trying to avoid mixing the
> concerns, which I think the locate( Class, query ) does.
Hmm, I don't think so. I agree that it fixes two potential problems
at the same time of the current framework:
1. Use Class as Type, and enforce its use in Framework
2. "Dynamic implementation selection" at runtime for a type
> The
> query still have to be passed off to someone else (container
> have no clue what to do with it), so why not inject "someone
> else" to the component?
My point is, that the container must have a clue. Now, let's take
a step back. Imagine you have a service interface (Football) and
one implementation A. In this case you somehow tell the container
that the implementation A should be used for the Football service.
A component needing the Football (nice example :) ), just looks
it up, but of course has to know how do to this. The simplest
solution imho is to say:
"I want a Football" which I would translate to something
like "locate(Football.class)".
The container knows that it has to deliver impl. A and everything is
fine.
So, the first step we could take now, is to agree that this approach
"locate(Football.class)" is more elegant than
"lookup('org.hedhman.niclas.sports.Football')".
(Again I'm just talking about framework).
If we agree on this we can do the next steps :)
WDYT?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 14 April 2004 17:05, Carsten Ziegeler wrote:
> How do you know what service "red-football" returns? (Ok, of
> course *you* know it), but anyone else seeing the above
> lookup might not know it.
Well, I am Merlin-user, and I think its solution is fairly elegant;
/**
* @avalon.dependency key="locator"
* type="org.hedhman.niclas.sports.FootballLocator"
*/
public void service( ServiceManager sm )
{
FootballLocator fbl = (FootballLocator) sm.lookup( "locator" );
:
}
<snip content="ROLE elaboration" reason="agree" />
> In addition by passing in the interface class, the container
> can check if the correct component (implementing the interface)
> is returned etc.
Merlin will ensure that the returned type in the above is a FootballLocator
and nothing else - guaranteed.
> Using custom keys like "red-football" that have no semantic
> meaning is imho not so good.
Ok, fair enough, I agree on that...
> > FootballLocator fbl = (FootballLocator) sm.lookup(
> > "footballs" ); Football ball = fbl.locate( "red" );
>
> Yes, we already have this approach by using ServiceSelectors
> which is way to complicated and leads to ugly rather ugly code.
Ugly? :o) Two lines instead of one? Or is it related to try{}catch{} stuff?
> > I think I don't understand where the Framework needs to be
> > involved, and that is what I am trying to understand...
>
> You can do everything already today without any problems, using
> ServiceSelectors etc. But imho these approaches are not elegant
> and in no way standardized. Introducing this new locator is
> a concrete and clear way.
Ok. ServiceSelectors are somewhat different, and that difference is the reason
why they are (and will remain) deprecated.
I think you are bringing up 2 issues;
1. Use Class as Type, and enforce its use in Framework.
2. Passing of auxillary selection information to the container.
I also assume that you are looking for a way so that for each Type, one can
define a LocatorHandler (didn't want to use the word Selector, but in
principle same thing)...
How about something like this?
If the component declare a method "someFunkyName()" which takes a single
argument which is a subinterface of "Locator", the container is responsible
to provide an implementation of such Locator type to the component.
public class MyComponent
{
public void locatorService( FootballLocator fbl )
{
Football ball = fbl.locate( "red" );
}
}
Looks very easy for the component author.
Do you think that would that be of help?
I am fishing around the bush, trying to avoid mixing the concerns, which I
think the locate( Class, query ) does. The query still have to be passed off
to someone else (container have no clue what to do with it), so why not
inject "someone else" to the component?
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Niclas Hedhman wrote:
>
> On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
>
> > This key should be a simple string,
> > so the above could read:
> > locator.locate(Football.class, "red");
>
> Forgive me for a naive question;
>
> What is the difference of the above, from;
>
> servicemanager.lookup( "red-football" ); or
> servicemanager.lookup( "/footballs/red" );
>
How do you know what service "red-football" returns? (Ok, of
course *you* know it), but anyone else seeing the above
lookup might not know it. The usual way of doing this,
has been:
servicemanager.lookup("package.Football/red");
So you use the interface name of the service for the lookup.
As this is errorprone because of typos, the ROLE constant
has been added to most service interfaces, so it
looks like this:
servicemanager.lookup(Football.ROLE + "/red");
But this requires to add this constant to the interface which
is bad.
In addition by passing in the interface class, the container
can check if the correct component (implementing the interface)
is returned etc.
Using custom keys like "red-football" that have no semantic
meaning is imho not so good.
> Or in the case you need someone else to figure it out;
>
> FootballLocator fbl = (FootballLocator) sm.lookup(
> "footballs" ); Football ball = fbl.locate( "red" );
>
Yes, we already have this approach by using ServiceSelectors
which is way to complicated and leads to ugly rather ugly code.
>
> I think I don't understand where the Framework needs to be
> involved, and that is what I am trying to understand...
>
You can do everything already today without any problems, using
ServiceSelectors etc. But imho these approaches are not elegant
and in no way standardized. Introducing this new locator is
a concrete and clear way.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 14 April 2004 15:40, Carsten Ziegeler wrote:
> This key should be a simple string,
> so the above could read:
> locator.locate(Football.class, "red");
Forgive me for a naive question;
What is the difference of the above, from;
servicemanager.lookup( "red-football" );
or
servicemanager.lookup( "/footballs/red" );
Or in the case you need someone else to figure it out;
FootballLocator fbl = (FootballLocator) sm.lookup( "footballs" );
Football ball = fbl.locate( "red" );
and the
public class MyOrdinaryComponent
implements FootballLocator
{
private ServiceManager sm;
public Football locate( String color )
{
if( color.equals( "red" ) )
return (Football) sm.lookup( "red-ball" );
if( color.equals( "blue" ) )
return (Football) sm.lookup( "blue-ball" );
if( color.equals( "green" ) )
return (Football) sm.lookup( "green-ball" );
return (Football) sm.lookup( "gray-ball" );
}
}
I think I don't understand where the Framework needs to be involved, and that
is what I am trying to understand...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> Hi Marcus!
>
> I've got some general questions about selection that perhaps
> you or other could fill me in on. First off - I'm separating
> out in my head three different things:
>
> 1. the interface we use for locating something (lets call
> it Locator for the purpose of discussion)
> 2. the interface used to supply and instance of a Locator
> to a component
> 3. the sort of information that a component can include
> in a locate request and the expected behavior of
> container in resolving such a request
>
> Item (3) is the thing that IMO needs to be expanded on.
Yes.
> Here
> is a couple of examples of an invocation followed by a couple
> of questions.
> Please not that I'm also not really worried about the
> argument or signatures just yet - so don't pay any attention
> to the approach - I'm in information gathering stage!
>
> public void someDeliveryMethod( Locator locator )
> {
> Map map = new Hashtable();
> map.put( "color", "red" );
> Football football = locator.locate( Football.class, map );
> }
>
> In the above the component implementation has to assume that
> a container has been configured such that "color" is
> understood - i.e. is translatable to something that will help
> in the determination of the appropriate instance to be returned.
>
> Possible interpretations:
>
> 1. color is an attribute of a component type
> 2. colour is an attribute of a service implemented by a
> a component type
> 3. color is a feature attributed to a component model
> (i.e. component model x has configuration y and is
> tagged with attribute color=red)
> 4. color is an attribute used by a selection handler
> that knows about the Football class
>
> Some questions:
>
> 1. if color is understood by a container, but no solution
> are resolvable - is that a failure or is the container
> obliged to return at least some football
>
> 2. which leads to the question .. should we be describing
> a Query object instead of a map? E.g.
>
> Constraint color = new Constraint( "color" );
> color.setRequired();
> color.setValue( "red" );
> locator.locate( Football.class, new Query[]{ color } );
>
Regardless of what we include as the information in the call to
locate, it should be as simply as possible. This information
is "evaluated" by the container and therefore it has to be
"configured" so the container can deliver the correct component.
In most cases, this extra information is not needed: this happens
when you have exactly one implementation for a service, so you
have one-to-one relationship.
However, the information is required as soon as you have a
one-to-many relationship. In this case, you the client might
want to exactly specify which implementation it want to use.
So, I think it's sufficient to give each implementation a key
for the container and the client uses this key when calling
the locate method. This key should be a simple string,
so the above could read:
locator.locate(Football.class, "red");
In my eyes this is simple but sufficient.
WDYT?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Stephen McConnell <mc...@apache.org>.
Hi Marcus!
I've got some general questions about selection that perhaps you or
other could fill me in on. First off - I'm separating out in my head
three different things:
1. the interface we use for locating something (lets call
it Locator for the purpose of discussion)
2. the interface used to supply and instance of a Locator
to a component
3. the sort of information that a component can include
in a locate request and the expected behavior of
container in resolving such a request
Item (3) is the thing that IMO needs to be expanded on. Here is a
couple of examples of an invocation followed by a couple of questions.
Please not that I'm also not really worried about the argument or
signatures just yet - so don't pay any attention to the approach - I'm
in information gathering stage!
public void someDeliveryMethod( Locator locator )
{
Map map = new Hashtable();
map.put( "color", "red" );
Football football = locator.locate( Football.class, map );
}
In the above the component implementation has to assume that a container
has been configured such that "color" is understood - i.e. is
translatable to something that will help in the determination of the
appropriate instance to be returned.
Possible interpretations:
1. color is an attribute of a component type
2. colour is an attribute of a service implemented by a
a component type
3. color is a feature attributed to a component model
(i.e. component model x has configuration y and is
tagged with attribute color=red)
4. color is an attribute used by a selection handler
that knows about the Football class
Some questions:
1. if color is understood by a container, but no solution
are resolvable - is that a failure or is the container
obliged to return at least some football
2. which leads to the question .. should we be describing
a Query object instead of a map? E.g.
Constraint color = new Constraint( "color" );
color.setRequired();
color.setValue( "red" );
locator.locate( Football.class, new Query[]{ color } );
Any thoughts?
Cheers, Stephen.
Marcus Crafter wrote:
> On Mon, 2004-04-12 at 16:35, Carsten Ziegeler wrote:
>
>>Niclas Hedhman wrote:
>>
>>>On Saturday 10 April 2004 00:24, Stephen McConnell wrote:
>>>
>>>
>>>>Secondly - concerning dynamic lookup I think we should be following
>>>>something closer to the approach suggested by Bruno Dumon - ie.:
>>>>
>>>> /**
>>>> * @avalon.dependency type="Locator" key="locator"
>>>> */
>>>> public void service( ServiceManager manager )
>>>> {
>>>> // get the ref widget
>>>> Locator locator = (Locator) manager.lookup( "locator" );
>>>> Widget redWidget = locator.locate( Widget.class, m_map );
>>>> }
>>>
>>The approach above is imho not better than the current Selector approach;
>>it's slightly different so.
>>I think you and Stephen are mixing the use of the lookup mechanism
>>in Merlin and the interface/functionality provided by the framework.
>>The framework api does not/should not know anything about meta info etc.
>>
>>But it seems noone else apart from me is interested in enhancing
>>the framework api, so we can skip this for now.
>
>
> I'm actually interested in enhancing this mate. A while back I asked
> about the use of Class in lookup rather than a String Role:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=105914629325097&w=2
>
> and there were various responses (rightly) pointing out the decisions
> behind it. I still tend to favour specifying the component you want by
> an interface Class instance, but I follow the reasoning behind using a
> String.
>
> With service selector, I sent in an RT a while back about parameterized
> lookups which from what I can tell is similar (at a usage level) to the
> 'locator' above:
>
> http://marc.theaimsgroup.com/?l=avalon-dev&m=105914503723538&w=2
>
> After getting some really informative responses I agree that
> parameterized lookup's aren't a good idea (eg. no type safety passing
> arbitrary maps to the container, etc).
>
> It would be great to fix up the service selector dilemma though, as it's
> been container specific for ages and ideally should be specified by the
> framework api.
>
> I remember when we had the old Avalon 5 emails we looked at having:
>
> Object lookup(String role, Object hint); // I agree hint isn't the best
> name
>
> Anyone remember the results of that discussion?
>
> Cheers,
>
> Marcus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Marcus Crafter <cr...@managesoft.com>.
On Mon, 2004-04-12 at 16:35, Carsten Ziegeler wrote:
> Niclas Hedhman wrote:
> >
> > On Saturday 10 April 2004 00:24, Stephen McConnell wrote:
> >
> > > Secondly - concerning dynamic lookup I think we should be following
> > > something closer to the approach suggested by Bruno Dumon - ie.:
> > >
> > > /**
> > > * @avalon.dependency type="Locator" key="locator"
> > > */
> > > public void service( ServiceManager manager )
> > > {
> > > // get the ref widget
> > > Locator locator = (Locator) manager.lookup( "locator" );
> > > Widget redWidget = locator.locate( Widget.class, m_map );
> > > }
> >
> The approach above is imho not better than the current Selector approach;
> it's slightly different so.
> I think you and Stephen are mixing the use of the lookup mechanism
> in Merlin and the interface/functionality provided by the framework.
> The framework api does not/should not know anything about meta info etc.
>
> But it seems noone else apart from me is interested in enhancing
> the framework api, so we can skip this for now.
I'm actually interested in enhancing this mate. A while back I asked
about the use of Class in lookup rather than a String Role:
http://marc.theaimsgroup.com/?l=avalon-dev&m=105914629325097&w=2
and there were various responses (rightly) pointing out the decisions
behind it. I still tend to favour specifying the component you want by
an interface Class instance, but I follow the reasoning behind using a
String.
With service selector, I sent in an RT a while back about parameterized
lookups which from what I can tell is similar (at a usage level) to the
'locator' above:
http://marc.theaimsgroup.com/?l=avalon-dev&m=105914503723538&w=2
After getting some really informative responses I agree that
parameterized lookup's aren't a good idea (eg. no type safety passing
arbitrary maps to the container, etc).
It would be great to fix up the service selector dilemma though, as it's
been container specific for ages and ideally should be specified by the
framework api.
I remember when we had the old Avalon 5 emails we looked at having:
Object lookup(String role, Object hint); // I agree hint isn't the best
name
Anyone remember the results of that discussion?
Cheers,
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Niclas Hedhman wrote:
>
> On Saturday 10 April 2004 00:24, Stephen McConnell wrote:
>
> > Secondly - concerning dynamic lookup I think we should be following
> > something closer to the approach suggested by Bruno Dumon - ie.:
> >
> > /**
> > * @avalon.dependency type="Locator" key="locator"
> > */
> > public void service( ServiceManager manager )
> > {
> > // get the ref widget
> > Locator locator = (Locator) manager.lookup( "locator" );
> > Widget redWidget = locator.locate( Widget.class, m_map );
> > }
>
> Carsten, I agree with the above, but I am not sure what
> concern you are really trying to address. I could use some
> more elaboration.
>
The approach above is imho not better than the current Selector approach;
it's slightly different so.
I think you and Stephen are mixing the use of the lookup mechanism
in Merlin and the interface/functionality provided by the framework.
The framework api does not/should not know anything about meta info etc.
But it seems noone else apart from me is interested in enhancing
the framework api, so we can skip this for now.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 10 April 2004 00:24, Stephen McConnell wrote:
> Secondly - concerning dynamic lookup I think we should be following
> something closer to the approach suggested by Bruno Dumon - ie.:
>
> /**
> * @avalon.dependency type="Locator" key="locator"
> */
> public void service( ServiceManager manager )
> {
> // get the ref widget
> Locator locator = (Locator) manager.lookup( "locator" );
> Widget redWidget = locator.locate( Widget.class, m_map );
> }
Carsten, I agree with the above, but I am not sure what concern you are really
trying to address. I could use some more elaboration.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
> <SNIP EXPLANATION OF MERLIN/>
Thanks Stephen for the info!
> >
> > MyComponent c = (MyComponent)this.serviceManager.lookup(
> > MyService.ROLE + '/' + hint );
> >
> > There is never a lookup that uses some custom role name, like
> > lookup("my-parser"); I think such lookups with custom role names
> > should not be used anyway as they are way too error-prone.
>
> It is only error prone if the lookup key is not scoped to the
> component implementation - for example in any merlin
> component a key is simply a convenience factor local to the
> implementation. The thing I think your getting at is when a
> string is passed to lookup who's semantics are relative to a
> configuration - which means that the component is tied to a
> particular deployment scenario - which is out and out bad.
Yes, exactly.
>
> > And even worse, ECM has the ugly concept of Selectors, so you first
> > lookup a selector using MyService.ROLE+"Selector" and then the
> > component from the selector using the hint. With the following
> > semantics you combine the two in one interface.
> >
> > Now, what do you think of using an easier solution:
> > public interface Locator {
> > Object lookup(Class clazz, String hint); // or Object hint }
>
> I *hate* the "hint" terminology. In English - hint means
> something I can use or ignore. If the string is a key - then
> call it a key - but beyond this - semantics are required.
Agreed: key is a better word (Don't know why the term hint has been
introduced
for this years ago).
> <SNIP/>
>
> Given validation of the above - with complete specification
> of a generic set of semantics of allowable map keys and
> values and the corresponding selection criteria/semantics -
> then you may have a framework candidate.
>
Hmm, I don't think that we have to do it that complicated.
Look at the current contracts of the framework: we have
service manager and service selector which is in combination
a rather ugly approach. So, my suggestion is just to
combine those two in a much nicer way.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Stephen McConnell <mc...@apache.org>.
Carsten Ziegeler wrote:
> After looking at several container frameworks, I think we should
> add a new lookup mechanism to the Avalon Framework.
> I know this issue has been discussed before several times, but why
> not doing it again after some years inbetween?
>
> Now with ECM and Fortress a Service (Interface) declares in most cases
> a constant ROLE, like this:
>
> public interface MyService {
> String ROLE = MyService.class.getName();
> ...
> }
>
> I don't know how this is done with Merlin.
The fundamental difference between Merlin and the Fortress/ECM approach
is "push" versus "pull". The following example is a pull based service
acquisition:
public void service( ServiceManager manager )
{
// ask the container to resolve a service
Widget widget =
(Widget) manager.lookup( Widget.class.getName() );
}
This basically is a component invoking a request on a container to
provide the Widget service. In both ECM and Fortress this results in
the potential establishment and delivery of the service to the component.
In Merlin things are "preemptive" - in that the component declares what
it needs as part of its definition. The result is that the component
will only be deployed IF all of its dependencies can be resolved prior
to the establishment of the component. This is achieved via the following:
/**
* @avalon.dependency type="org.whatever.Widget"
*/
public void service( ServiceManager manager )
{
// ask the container to give me the widget it has
// already established for me
Widget widget =
(Widget) manager.lookup( Widget.class.getName() );
}
This approach can be simplified for the component implementation by
declaring a lookup key (note tag declaration and lookup argument):
/**
* @avalon.dependency type="org.whatever.Widget" key="widget"
*/
public void service( ServiceManager manager )
{
// ask the container to give me the widget it has
// already established for me
Widget widget =
(Widget) manager.lookup( "widget" );
}
> Anyways, the lookup is then done using this constant:
>
> MyComponent c = (MyComponent)this.serviceManager.lookup( MyService.ROLE );
>
> or
>
> MyComponent c = (MyComponent)this.serviceManager.lookup( MyService.ROLE +
> '/' + hint );
>
> There is never a lookup that uses some custom role name, like
> lookup("my-parser"); I think such lookups with custom role names
> should not be used anyway as they are way too error-prone.
It is only error prone if the lookup key is not scoped to the component
implementation - for example in any merlin component a key is simply a
convenience factor local to the implementation. The thing I think your
getting at is when a string is passed to lookup who's semantics are
relative to a configuration - which means that the component is tied to
a particular deployment scenario - which is out and out bad.
> And even worse, ECM has the ugly concept of Selectors, so you first
> lookup a selector using MyService.ROLE+"Selector" and then the
> component from the selector using the hint. With the following semantics
> you combine the two in one interface.
>
> Now, what do you think of using an easier solution:
> public interface Locator {
> Object lookup(Class clazz, String hint); // or Object hint
> }
I *hate* the "hint" terminology. In English - hint means something I
can use or ignore. If the string is a key - then call it a key - but
beyond this - semantics are required. What does the key refer to? This
is critical thing missing in the Selector spec - no declaration of
semantics. Before considering any alternative the semantic contract
needs to be nailed down tight .. and only then one should consider if
this is a framework concern.
> With this interface, you don't need the ROLE constant anymore and the
> container can check the type of the returned object avoiding class cast
> exceptions.
+1 to removal of anything dependent on ROLE constants.
> And you can see directly in your code which type is returned
> by the lookup. (Creating proxies is also a little bit easier as the lookup
> method knows which interface to proxy without having the need to get
> this information from somewhere else).
>
> This approach is also used by other container frameworks and imho it gives
> the lookup method more meaning and reduces errors because of typos.
>
> So, I propose to add a new interface with this lookup semantics to avalon
> framework with a corresponding IoC interface to give this locator to
> components.
Let's not talk about the framework - instead - get something in place
using a facility - validate it, get the specs real clear - and then
assess the necessity for inclusion in the framework. Immediate
impressions are the the class argument is only required in pure dynamic
lookup context in which case we are talking about finder semantics. As
such I think the entire subject of the qualifying argument needs to be
more fully addressed:
(a) properties of a component type?
(b) properties of a service descriptor?
(c) properties of a deployment scenario?
Beyond this there are the semantics of the request values:
(a) exact matching
(b) regular expression matching
(c) candidate selection
> The default implementation for all containers at avalon could be that
> a lookup(Class clazz, String hint) is "converted" to a
> serviceManager.lookup(clazz.getName()) if hint is null or
> serviceManager.lookup(clazz.getName() + '/' + hint) otherwise.
>
> WDYT?
I think we should break this into two things - firstly selection
relative to component type attributes and service attributes - e.g:
/**
* @avalon.dependency type="Widget" color="red" key="widget"
*/
public void service( ServiceManager manager )
{
// get the ref widget
Widget widget = (Widget) manager.lookup( "widget" );
}
Secondly - concerning dynamic lookup I think we should be following
something closer to the approach suggested by Bruno Dumon - ie.:
/**
* @avalon.dependency type="Locator" key="locator"
*/
public void service( ServiceManager manager )
{
// get the ref widget
Locator locator = (Locator) manager.lookup( "locator" );
Widget redWidget = locator.locate( Widget.class, m_map );
}
Given validation of the above - with complete specification of a generic
set of semantics of allowable map keys and values and the corresponding
selection criteria/semantics - then you may have a framework candidate.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] New Lookup mechanism
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
> Also lets stop talking about 'hints'. These are keys so why not just
> call them that?
++1
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] New Lookup mechanism
Posted by Alex Karasulu <ao...@bellsouth.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
<snip/>
> Now, what do you think of using an easier solution:
> public interface Locator {
> Object lookup(Class clazz, String hint); // or Object hint
> }
>
> WDYT?
This seems to me to be a sensible approach. Why something this
simple is not used into first place is beyond me.
I'd like to see this experimented with using Merlin which lacks
the selector approach and in my opinion is cleaner for it: I just
really dislike the mechanism where a composite String based key is
constructed by concatenation. However Merlin does need a clean
selector substitute. This mechanism might be what it was
waiting for.
Also lets stop talking about 'hints'. These are keys so why not just
call them that?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org