Are these DS components? I'm not entirely sure what would happen if a component both provides a service and binds to the same service type. In theory it might be able to bind to itself, especially if it is a lazy (delayed) service component, because then the service registration exists before the component is activated. But possibly SCR prevents this scenario, I'm not sure.
A safe way to protect against this regardless is to use properties and filters. For example the AppSessionServiceImpl can provide the SessionService with a property such as app=true. Then it would bind to SessionService with a target filter of (!(app=*)). Neil On Fri, Aug 3, 2018 at 1:17 PM, Alain Picard via osgi-dev < [email protected]> wrote: > Facing an issue and looking for the right pattern to apply where I have a > service interface that is extended and at run time I want to always run the > most appropriate one. Each extension provides additional method to the API. > > As an example (posted here: https://github.com/castortech/ > osgi-test-session), there's a CoreSessionService ifc (no direct > implementation) that will be used by core part of the code. There is an > extension to it (SessionService ifc) that adds some new methods and can be > used by common level modules and then we have the AppSessionService that is > app specific and can exist for some apps and not for other, which would > then rely on the SessionServiceImpl. > > My issue is that for example the AppSessionServiceImpl needs a reference > to the SessionService and this either creates a circular dependency (tried > to use the Top/Bottom approach in the seminal Concurrency paper from > enRoute) but that is not working so far. > > Any hints on how to proceed here. > > Thanks > Alain > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
