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 [email protected]
