Thanks Neil and Tim. I was able to use the target to avoid the circularity, but my tests so far are not conclusive. I will keep at it and might have further questions.
Alain On Fri, Aug 3, 2018 at 8:52 AM Tim Ward <tim.w...@paremus.com> wrote: > 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> 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 >> 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
