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? >
:-D 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. -- Unico * 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
