Hi, Not sure it would meet your requirements, but in the 1.10.x, we added service dependency interceptors. Interceptors are external entities involved in the service resolution. We have 3 types on interceptors:
- tracking interceptors allow hiding services, or selecting the set of services seen by the service dependency (the LDAP filter is a tracking interceptor) - ranking interceptors can change the order of the services (the comparator is a ranking interceptor) - binding interceptors can change the injected service objects (to be used with caution ;-)) You can, without too much effort, write an interceptor that will shape the processor list as you want. As said above, interceptors are external entities. Actually, they are services with a special 'target' property indicating in which dependencies they want to be involved. So, an interceptor can select one very specific dependency, all dependencies of an instance, all dependencies targeting a specific interface… Unfortunately, there is a long overdue issue about interceptors: FELIX-4136 Document service dependency interceptors. Best regards, Clement On 2 oct. 2013, at 15:57, Bengt Rodehav <[email protected]> wrote: > Thanks for your reply Richard. > > I am using a lifecycle controller already to make it possible to > enable/disable my services via a GUI. I'll see if I can use it for this > purpose. > > I've also tried the following approach: Keep track of all possible services > that expose the interface I'm intererested in as follows: > > @Requires(optional = true) > private IOrchestrationProcessor[] mProcessors; > > In runtime, when my service is being activated (prior to creating the camel > route) I check to see if all required processors exist, if not I throw an > exception. Unfortunately I have no control of in what order the services > will be activated so its hard to ever get the camel route created this way. > A lot of the time a "required" services is activated a bit later. > > /Bengt > > > > 2013/10/2 Richard S. Hall <[email protected]> > >> >> On 10/2/13 08:42 , Bengt Rodehav wrote: >> >>> I'm creating a dynamic processing component using iPOJO and Camel. The >>> idea >>> is to dynamically specify (via config admin) a number of processor id's. >>> In >>> runtime I want to find the matching processors (the processors are Camel >>> processors published as OSGi services) with the correct id. >>> >>> E g if I specify a list of services to {A,B} (FileInstall recognizes this >>> as a list). I want to require those services in order for my iPojo >>> instance >>> to become valid. It was much harder than I thought. >>> >>> I've tried something like: >>> >>> @Property(name = "processors", mandatory = false, value = "") >>> public void setProcessors(String[] theProcessorIds) { >>> mProcessorIds = theProcessorIds; >>> updateProcessorFilter(); >>> } >>> >>> @Requires >>> private Processor[] mProcessors; >>> >>> The idea is that whenever the configuration property "processors" is >>> updated, I dynamically update the ldap filter on the dependency >>> mProcessors. I've used this approach before and it has worked when using a >>> single dependency (not an array). >>> >>> The problem is that I want to specifically require each specified >>> processor. In the example above, I require one processor with id=A AND one >>> processor with id=B. It's not enough with anyone of them since I want to >>> invoke them one after another. >>> >>> Can I use a filter for this? I've been thinking of something like this: >>> >>> (|(processorId=A)(processorId=**B)) >>> >>> This would match both my processors but if one of them were missing my >>> instance would still become valid which I don't want. >>> >> >> I don't think there is anyway to do what you want. This is essentially an >> "N cardinality" requirement, where you want to say that you require >> specifically N of something. Such requirements had been discussed over the >> years for Service Binder, Declarative Services, etc., but we could never >> agree on their usefulness or how to do them, so we just left it as it is >> now (i.e., optional, at least one...). >> >> Other than adding some sort of threshold to service dependencies, I don't >> see this happening. You could potentially create an iPOJO lifecycle >> controller that would keep your component invalid until it matched the >> required number of services (if you can get this information in the >> handler)...or perhaps write/extend the service dependency handler. >> >> -> richard >> >> >>> /Bengt >>> >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@felix.**apache.org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
