On Fri, Nov 18, 2011 at 1:53 PM, Rupert Westenthaler < [email protected]> wrote:
> > On 18.11.2011, at 13:05, Reto Bachmann-Gmür wrote: > > > Hi Rupert > > > > You can have a servicereference as argument to the bind method and > > dereference them when the prerequisites are met. > > > > That is good to know however it does not solve my problem, because the > filter used to determine ServiceReference parsed to my instance would still > need to be fixed. My problem is that I know some constraints of the Filter > only at runtime. > > I will try to give a less abstract example: > > A user configures via the Apache Felix Webconsole that the > KeywordExtractionEngine should use the taxonomy "gemet". Therefore this > engine depends on the ReferencedSite with the name "gemet". If he changes > the configuration to "dbpedia", than I need to change the filter, because > now the engine depends on the ReferencedSite with the name "dbpedia". > > Now lets assume that the ReferencedSite for "dbpedia" is not yet active, > because the download/initialization of the 5gByte if data is still in > progress. 30minutes later the initialization completes and the "dbpedia" > ReferencedSite becomes available. > > If I could use @References now the Declarative Services would > automatically also activate the KeywordExtractionEngine for dbpedia. > However up to now I do not now how to use this feature with runtime > dependencies. > It seems to me that doing the selection in the bind-method would be an alternative to the more restrictive filter. However I'm sceptical that it is good if the KeywordExtractionEngine has to be configured to use a service or another. Why not just allways use the ReferencedSite with the highest ranking? If RefererencedSite is to generic we could have an OntologyProvider service interface implemented by a GemetProvider as well as a DbpediaProvider. Cheers, Reto > best > Rupert > > > Cheers, > > Reto > > On Nov 18, 2011 11:48 AM, "Rupert Westenthaler" < > > [email protected]> wrote: > > > >> Hi > >> > >> The situation (in pseudo code) > >> > >> @Component(configurationFactory = true) > >> MyServiceImpl { > >> > >> ServiceTracker requiredServiceTracker; > >> > >> void activate(ComponentContext context) { > >> //create Filter based on properties of the context > >> Filter filter; > >> requiredServiceTracker = new ServiceTracker(filter); > >> } > >> > >> } > >> > >> What I want to do is to switch Component instances to "unsatisfied" as > >> soon as the required service becomes unavailable and back to the > "activate" > >> state as soon as it becomes available again. > >> > >> If I would use @Reference than the Declarative Services would take care > of > >> activating the service as soon as all dependencies are available. > However I > >> con not use @Reference here, because the parameter for the Filter are > only > >> available at runtime an filters in @Reference annotations need to be > static. > >> > >> So basically I am searching for a way (interface, extension point) that > >> allows me to use the same System with "runtime" dependencies. > >> > >> any Ideas? > >> > >> best > >> Rupert > >
