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: [email protected] For additional commands, e-mail: [email protected]
