felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clement Escoffier <clement.escoff...@gmail.com>
Subject Re: iPOJO and dynamic requires
Date Wed, 02 Oct 2013 16:25:30 GMT

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

- 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,


On 2 oct. 2013, at 15:57, Bengt Rodehav <bengt@rodehav.com> 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 <heavy@ungoverned.org>
>> 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<users-unsubscribe@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message