Re: [osgi-dev] Extending Services

[Alain Picard via osgi-dev]

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

Re: [osgi-dev] Extending Services

[Tim Ward via osgi-dev]

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

Re: [osgi-dev] Extending Services

[Neil Bartlett via osgi-dev]

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-dev] Extending Services

[Alain Picard via osgi-dev]

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