Impact of multi-valued SERVICE_PID?

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

SLING-5827 shows that our code can fail where it (wrongly) assumes
that the Constants.SERVICE_PID service property is just a String.

As per [1] however that can be multi-valued, already in OSGi R4 - but
I had never seen that happen before.

My impression so far was that using that PID as a unique key for a
component is fine, but if it can be multi-valued we need to be careful
if using it as a key. Maybe create a specific utility in our
commons.osgi module for safely converting it to a stable unique ID.

I've done a rough analysis in SLING-5828 of where we need to change
this, could our OSGi gurus comment?

-Bertrand

[1] https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#SERVICE_PID

Re: Impact of multi-valued SERVICE_PID?

[Carsten Ziegeler <cz...@apache.org>]

I've commented in the issue - in general code should not rely on
SERVICE_PID, that's not stable. This property might be missing as well.

Usually SERVICE_ID is the one you're looking for.

Therefore let's not create a common utility method as it really should
not be used.

From the list in the issue:
- resourceresolver: it checks the PID of a provider against a
configuration, so we need to handle the array case. Which should really
be simple.
- event: that should be fine, 100% internal usage
- installer/factory/configuration: should be fine as this is used for
internal data structures, but not for service properties

I didn't check the others from that list.

Carsten

Bertrand Delacretaz wrote
> Hi,
> 
> SLING-5827 shows that our code can fail where it (wrongly) assumes
> that the Constants.SERVICE_PID service property is just a String.
> 
> As per [1] however that can be multi-valued, already in OSGi R4 - but
> I had never seen that happen before.
> 
> My impression so far was that using that PID as a unique key for a
> component is fine, but if it can be multi-valued we need to be careful
> if using it as a key. Maybe create a specific utility in our
> commons.osgi module for safely converting it to a stable unique ID.
> 
> I've done a rough analysis in SLING-5828 of where we need to change
> this, could our OSGi gurus comment?
> 
> -Bertrand
> 
> [1] https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Constants.html#SERVICE_PID
> 


 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org