avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: [FYI] Eclipse moving to OSGi
Date Wed, 03 Dec 2003 10:15:55 GMT

Sylvain Wallez wrote:
> Unico Hommes wrote:
> >Sylvain Wallez wrote:
> >  
> >
> <snip/>
> >>An OSGi "bundle" (that's the term for the deployment unit) 
> can provide 
> >>several services: a "BundleActivator" class inside the bundle 
> >>registers the provided services (there can be several) when 
> the bundle 
> >>is loaded.
> >>
> >>Registering a service consists in registering an instance of the 
> >>service interface with additionnal properties that describe 
> the service. The lookup mechanism then allows to select a 
> particular implementation of the service depending on 
> property values, by using a simple LDAP-like query language.
> >>    
> >>
> >
> >Hmm, I like this. This is something that is still missing 
> from Avalon 
> >IMHO: richer service lookup semantics. I've had several 
> instances where I needed this.
> >  
> >
> Having the "hint" as an Object in ComponentSelector was 
> exactly for this 
> purpose. IIRC, there even was a Query class that was 
> discussed some time.
> Can you give more details about your use case?


I got up this morning with exactly this on my mind.

Actually I thought I had a case for the componentized treeprocessor
proposal in cocoon 2.2 but on the bikeride on my way to the office this
morning I realized there was a solution I hadn't thought of yet that
would work with the current avalon lookup semantics.*

The other case I have been thinking about in particular has to do with
work I recently did regarding property management on excalibur sources.
At that time I sent a mail to the avalon users list about it. Basically,
the idea is of pluggable source property handlers to enable property
assignment from different data sources (SQL, LDAP, WebDAV, etc.) A
property handler will register itself to handle properties of a
particular type. Whenever a client wants to query a source for a
particular property it must lookup the property handler for that
property. So in this case a query can be something like "give me the
property handlers that handle properties IMG:size or DAV:authors". 

The current 'solution' to this is to have a special property handler
that acts as a container to a set of property handlers and just loops
through this set in search of the property that is being queried.


* The case here was view management. I was thinking that branch point
statements (generate, transform, serialize) could benefit from a query
enabled lookup mechanism in order to be able to say something like "give
me all the views that are declared to branch at label x, y, or z". This
is actually akin to the current implementation in that branch point
nodes obtain its views during initialization.

The way the need for such a lookup query can be avoided is to let branch
points lookup views by their name at runtime. If we register views using
their names as lookup hint and then try to do a lookup the first time a
particular view is requested - and verifying whether it actually is a
branch point for the current node by comparing the labels - then this
should solve the problem.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message