Re: [osgi-dev] service tracker precedence
In addition to the caveats from Chris and Marcel, I would add that service hooks can only filter at the consuming bundle level. They cannot distinguish between multiple trackers coming from the same bundle. Regards Neil On 15 Apr 2015, at 13:10, Marcel Offermans marcel.offerm...@luminis.nl wrote: And even those probably only work if you manage to actually install the bundle with the hook before the other bundles... On 15 Apr 2015 at 13:56:01, chris.g...@kiffer.be (chris.g...@kiffer.be mailto:chris.g...@kiffer.be) wrote: With the caveat that service registry hooks are significantly harder to get right than service trackers. But indeed this is the only way to hide services from being found through the regular channels. A service tracker might be the wrong thing to use for your case. Instead you might want to look into the service registry hooks. This should allow you to intercept the lookup of the tracker SA and filter out the services it should not see. http://coderthoughts.blogspot.de/2009/11/altering-osgi-service-lookups-with.html Christian On 15.04.2015 12:52, Frank Langel wrote: Hi, Short question regarding service tracker concept if I may: 1. I have two service tracker SA and SB tracking the same service S 2. SA is out of the box and cannot not be modified 3. SB is my own service tracker I want to make sure that my service tracker SB always tracks/finds the service first, and if it decides to track the service, SA will not be triggered/invoked and therefore have no way of tracking it. Would giving SA und SB different service.ranking do the trick ? ( I don¹t think so ). How do I stop SB from being notified about S ? Is that possible? Any pointers would be highly appreciated Thanks a lot Frank ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org mailto:osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] service tracker precedence
org.osgi.framework.hooks.service.EventListenerHook.event(ServiceEvent, MapBundleContext, CollectionListenerInfo) That hook was introduced to be able to distinguish between the different listeners (trackers) for a specific bundle. But I agree with others, hooks are not the most simple thing to get right. Tom From: Neil Bartlett njbartl...@gmail.com To: OSGi Developer Mail List osgi-dev@mail.osgi.org Date: 04/15/2015 07:32 AM Subject:Re: [osgi-dev] service tracker precedence Sent by:osgi-dev-boun...@mail.osgi.org In addition to the caveats from Chris and Marcel, I would add that service hooks can only filter at the consuming bundle level. They cannot distinguish between multiple trackers coming from the same bundle. Regards Neil On 15 Apr 2015, at 13:10, Marcel Offermans marcel.offerm...@luminis.nl wrote: And even those probably only work if you manage to actually install the bundle with the hook before the other bundles... On 15 Apr 2015 at 13:56:01, chris.g...@kiffer.be (chris.g...@kiffer.be) wrote: With the caveat that service registry hooks are significantly harder to get right than service trackers. But indeed this is the only way to hide services from being found through the regular channels. A service tracker might be the wrong thing to use for your case. Instead you might want to look into the service registry hooks. This should allow you to intercept the lookup of the tracker SA and filter out the services it should not see. http://coderthoughts.blogspot.de/2009/11/altering-osgi-service-lookups-with.html Christian On 15.04.2015 12:52, Frank Langel wrote: Hi, Short question regarding service tracker concept if I may: 1. I have two service tracker SA and SB tracking the same service S 2. SA is out of the box and cannot not be modified 3. SB is my own service tracker I want to make sure that my service tracker SB always tracks/finds the service first, and if it decides to track the service, SA will not be triggered/invoked and therefore have no way of tracking it. Would giving SA und SB different service.ranking do the trick ? ( I don¹t think so ). How do I stop SB from being notified about S ? Is that possible? Any pointers would be highly appreciated Thanks a lot Frank ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] service tracker precedence
And even those probably only work if you manage to actually install the bundle with the hook before the other bundles... On 15 Apr 2015 at 13:56:01, chris.g...@kiffer.be (chris.g...@kiffer.be) wrote: With the caveat that service registry hooks are significantly harder to get right than service trackers. But indeed this is the only way to hide services from being found through the regular channels. A service tracker might be the wrong thing to use for your case. Instead you might want to look into the service registry hooks. This should allow you to intercept the lookup of the tracker SA and filter out the services it should not see. http://coderthoughts.blogspot.de/2009/11/altering-osgi-service-lookups-with.html Christian On 15.04.2015 12:52, Frank Langel wrote: Hi, Short question regarding service tracker concept if I may: 1. I have two service tracker SA and SB tracking the same service S 2. SA is out of the box and cannot not be modified 3. SB is my own service tracker I want to make sure that my service tracker SB always tracks/finds the service first, and if it decides to track the service, SA will not be triggered/invoked and therefore have no way of tracking it. Would giving SA und SB different service.ranking do the trick ? ( I don¹t think so ). How do I stop SB from being notified about S ? Is that possible? Any pointers would be highly appreciated Thanks a lot Frank ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] service tracker precedence
Then you have been lying to us when you said that provider A cannot be changed; you have the source code. ;-) Trying to make a delegating proxy like this is really quite hard, believe me (and others in this thread). Are you saying that B should use a persistent and distributed event handling system if one is available, otherwise it just delegates to A? And that the consumers couldn't care less which happens? I have my doubts about that last bit, and if they *do* care then they should be able to express this in a filter. Yep, thought so. Idea was to have two EventAdmin implementations * Provider A is the fellix event admin impl * Provider B is a custom implementation providing additional functionality/capabilities Provider B is registering a service of type EventHandler if that event handler service has some specific properties, else A is used. In my case, B provides persistent and distributed messaging implementation. Does that make sense? Thanks Frank From: Marcel Offermans marcel.offerm...@luminis.nl Date: Wednesday, April 15, 2015 at 12:59 PM To: Frank Langel fr...@frankjlangel.com, OSGi Developer Mail List osgi-dev@mail.osgi.org Subject: Re: [osgi-dev] service tracker precedence Greetings, Marcel ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] service tracker precedence
Yep, thought so. Idea was to have two EventAdmin implementations * Provider A is the fellix event admin impl * Provider B is a custom implementation providing additional functionality/capabilities Provider B is registering a service of type EventHandler if that event handler service has some specific properties, else A is used. In my case, B provides persistent and distributed messaging implementation. Does that make sense? Thanks Frank From: Marcel Offermans marcel.offerm...@luminis.nl Date: Wednesday, April 15, 2015 at 12:59 PM To: Frank Langel fr...@frankjlangel.com, OSGi Developer Mail List osgi-dev@mail.osgi.org Subject: Re: [osgi-dev] service tracker precedence Greetings, Marcel ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] service tracker precedence
So if a client wants to send an event, how does it determine which EventAdmin service to use (A or B)? The most straightforward implementation to me would be to have provider B publish EventAdmin with an extra service property and then let clients either choose an EventAdmin that has that property, or not. On 15 Apr 2015 at 21:11:02, Frank Langel (fr...@frankjlangel.com) wrote: Yep, thought so. Idea was to have two EventAdmin implementations Provider A is the fellix event admin impl Provider B is a custom implementation providing additional functionality/capabilities Provider B is registering a service of type EventHandler if that event handler service has some specific properties, else A is used. In my case, B provides persistent and distributed messaging implementation. Does that make sense? Thanks Frank From: Marcel Offermans marcel.offerm...@luminis.nl Date: Wednesday, April 15, 2015 at 12:59 PM To: Frank Langel fr...@frankjlangel.com, OSGi Developer Mail List osgi-dev@mail.osgi.org Subject: Re: [osgi-dev] service tracker precedence Greetings, Marcel ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] service tracker precedence
Hi, Short question regarding service tracker concept if I may: 1. I have two service tracker SA and SB tracking the same service S 2. SA is out of the box and cannot not be modified 3. SB is my own service tracker I want to make sure that my service tracker SB always tracks/finds the service first, and if it decides to track the service, SA will not be triggered/invoked and therefore have no way of tracking it. Would giving SA und SB different service.ranking do the trick ? ( I don¹t think so ). How do I stop SB from being notified about S ? Is that possible? Any pointers would be highly appreciated Thanks a lot Frank ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] service tracker precedence
Service Trackers are no services, so they have no service ranking, so what you propose is not possible. What, at a higher level, are you trying to achieve with the mechanism you describe? Greetings, Marcel On 15 Apr 2015 at 12:56:02, Frank Langel (fr...@frankjlangel.com) wrote: Hi, Short question regarding service tracker concept if I may: 1. I have two service tracker SA and SB tracking the same service S 2. SA is out of the box and cannot not be modified 3. SB is my own service tracker I want to make sure that my service tracker SB always tracks/finds the service first, and if it decides to track the service, SA will not be triggered/invoked and therefore have no way of tracking it. Would giving SA und SB different service.ranking do the trick ? ( I don¹t think so ). How do I stop SB from being notified about S ? Is that possible? Any pointers would be highly appreciated Thanks a lot Frank ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
