I agree with Neil that, in general, you don’t want to reference a service of the same type that you advertise without something to prevent you wiring to yourself.
Service properties are a good way to do this, but so is type safety. For example does it really make sense for the AppSessionServiceImpl to advertise as a CoreSessionService? Would someone looking in the service registry for a CoreSessionService really be ok with having the ApplicationSessionService come back? In fact, what I’m trying to say is “is it really the right thing for these advertised interfaces to extend one another?”. The often stated rule is to prefer composition over inheritance, which the implementation is doing here, but the API isn’t. It seems odd to me that an “Application specific session service” would also be a “core platform session service” as well as a generic session service. You might well have some interfaces defining common the methods, but the advertised service interfaces really feel like they should be different type hierarchies. At this point you would no longer run the risk of wiring to a service that isn’t appropriate (for example one application delegating to another application seems like a bad idea). Best Regards, Tim > On 3 Aug 2018, at 13:41, Neil Bartlett via osgi-dev <osgi-dev@mail.osgi.org> > wrote: > > 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 > <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> 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 > <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 > 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
