You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2016/07/13 06:01:55 UTC
Reconsider usage of service PID
Hi,
we already found some problems with checking for the PID in our code
recently, but actually the problem is slightly worse.
Now, short story is : don't rely on the service PID.
It's really an implementation detail and it's not guaranteed to exist.
Unfortunately so far it worked for us as we're mostly using DS for our
components with the maven-scr-plugin and that plugin has a bug from the
first version on (FELIX-5304) which always adds a PID property to every
component. However this property should never be set by the component,
it's managed by DS and is only set if there is really a configuration
used for the component.
We really have to fix our code and get rid of most of the usage of PIDs
Of course there are some valid cases but they are really rare.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Reconsider usage of service PID
Posted by Konrad Windszus <ko...@gmx.de>.
Thanks a lot for the clarification. I was wrongly assuming that the connection is made by leveraging the SERVICE_PID property of the component, which is now no longer set by default by the maven-scr-plugin (https://issues.apache.org/jira/browse/FELIX-5304 <https://issues.apache.org/jira/browse/FELIX-5304>). But the actual logic is vice-versa, so the configuration PID determines the automatically set SERVICE_PID not the other way round.
Thanks a lot for the explanation.
Konrad
> On 20 Jul 2016, at 18:18, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> Hi Carsten,
>> I am just wondering because you said the service PID is an implementation detail and being generated automatically by DS (in case the service has been started by DS), if we can always rely on the PID being the component's class name for all Felix version's in the future.
>
> The component xml for a DS component has an attribute for a PID, so a
> developer can specify a PID. If not specified it defaults to the
> component name, again something the developer can specify. If that one
> is not defined by the developer, it falls back to the class name.
>
> So, yes, the default is the class name.
>
>> I just don't know how the connection is made between the service and its configuration in case the service is already running (and just a new configuration should be bound).
>
> It's based on the PID, DS looks up the configuration using the PID(s)
> specified in the component XML.
>
>> In case I want to deploy a configuration through the OSGi installer, I want to make sure it gets bound to the right component.
>
> As you're the developer of the component, you know it's PID, as its you
> who defines it in the first place.
>
>>
>> Have you any reference about the format of the PID which must be used here?
>
> Usually it uses reverse domain names and class names of implementations
> are pretty good PIDs as they are mostly unique - unless it happens that
> you deploy two different bundles which happen to have the same
> implementation class. That's why the below text states to use the
> bundle's identifier. But using bundle Id is of course problematic as you
> don't know it up front. Therefore being pragmatic and using class names
> usually does the trick.
>
> Or in short, nothing changes for how we develop components or configure
> them. The only thing we have to check where our code is using the
> SERVICE_PID, if that usage is ok.
>
> Carsten
>
>> In OSGi Core 6.0.0, 10.1.15.106 it just says
>>
>> public static final String SERVICE_PID = "service.pid"
>> Service property identifying a service's persistent identifier.
>> This property may be supplied in the properties Dictionary object passed to the
>> BundleContext.registerService method. The value of this property must be of type String, String[],
>> or Collection of String.
>> A service's persistent identifier uniquely identifies the service and persists across multiple Framework
>> invocations.
>> By convention, every bundle has its own unique namespace, starting with the bundle's identifier
>> (see Bundle.getBundleId()) and followed by a dot (.). A bundle may use this as the prefix of the persistent
>> identifiers for the services it registers.
>>
>>
>> Konrad
>>
>>> On 20 Jul 2016, at 17:42, Carsten Ziegeler <cz...@apache.org> wrote:
>>>
>>>> What about usage of PIDs when providing configurations through the repository (as sling:OsgiConfig resources or configuration files as described in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html>) for the OSGi installer. The resource names are supposed to be (at least starting with the) PID, e.g. mentioned in https://sling.apache.org/documentation/bundles/osgi-installer.html <https://sling.apache.org/documentation/bundles/osgi-installer.html> and https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
>>>> Is this really the PID here?
>>>> Is there some cleaning in order on the documentation or the implementation side for the OSGi Installer as well?
>>>
>>> The documentation is correct, configuration is based on PIDs. A
>>> component either registers a ManagedService configured with a PID to get
>>> the configuration with that PID or you're using a component framework
>>> like Declarative Services which does the trick for you.
>>>
>>> So we're good on that front and in general I think we only have a few
>>> places where the usage is wrong. It usually always when you want to have
>>> a unique handle for a service.
>>>
>>>>
>>>> I am wondering though, why only the PID is exposed in system/console/services/xxx and not the service id.
>>>
>>> The first column "Id" is the service ID :)
>>>
>>> Carsten
>>>
>>>> Konrad
>>>>
>>>>
>>>>> On 13 Jul 2016, at 12:07, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>>
>>>>>> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>>>> ...We really have to fix our code and get rid of most of the usage of PIDs...
>>>>>>
>>>>>> And use SERVICE_ID instead when we need a unique key to the service?
>>>>>>
>>>>> Yes, right
>>>>>
>>>>> Btw, I fixed the health check core bundle, not sure which others need to
>>>>> be fixed. But I guess the list is really short
>>>>>
>>>>> Regards
>>>>>
>>>>> Carsten
>>>>>
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziegeler@apache.org
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>
>>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org <ma...@apache.org>
Re: Reconsider usage of service PID
Posted by Carsten Ziegeler <cz...@apache.org>.
> Hi Carsten,
> I am just wondering because you said the service PID is an implementation detail and being generated automatically by DS (in case the service has been started by DS), if we can always rely on the PID being the component's class name for all Felix version's in the future.
The component xml for a DS component has an attribute for a PID, so a
developer can specify a PID. If not specified it defaults to the
component name, again something the developer can specify. If that one
is not defined by the developer, it falls back to the class name.
So, yes, the default is the class name.
> I just don't know how the connection is made between the service and its configuration in case the service is already running (and just a new configuration should be bound).
It's based on the PID, DS looks up the configuration using the PID(s)
specified in the component XML.
> In case I want to deploy a configuration through the OSGi installer, I want to make sure it gets bound to the right component.
As you're the developer of the component, you know it's PID, as its you
who defines it in the first place.
>
> Have you any reference about the format of the PID which must be used here?
Usually it uses reverse domain names and class names of implementations
are pretty good PIDs as they are mostly unique - unless it happens that
you deploy two different bundles which happen to have the same
implementation class. That's why the below text states to use the
bundle's identifier. But using bundle Id is of course problematic as you
don't know it up front. Therefore being pragmatic and using class names
usually does the trick.
Or in short, nothing changes for how we develop components or configure
them. The only thing we have to check where our code is using the
SERVICE_PID, if that usage is ok.
Carsten
> In OSGi Core 6.0.0, 10.1.15.106 it just says
>
> public static final String SERVICE_PID = "service.pid"
> Service property identifying a service's persistent identifier.
> This property may be supplied in the properties Dictionary object passed to the
> BundleContext.registerService method. The value of this property must be of type String, String[],
> or Collection of String.
> A service's persistent identifier uniquely identifies the service and persists across multiple Framework
> invocations.
> By convention, every bundle has its own unique namespace, starting with the bundle's identifier
> (see Bundle.getBundleId()) and followed by a dot (.). A bundle may use this as the prefix of the persistent
> identifiers for the services it registers.
>
>
> Konrad
>
>> On 20 Jul 2016, at 17:42, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>> What about usage of PIDs when providing configurations through the repository (as sling:OsgiConfig resources or configuration files as described in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html>) for the OSGi installer. The resource names are supposed to be (at least starting with the) PID, e.g. mentioned in https://sling.apache.org/documentation/bundles/osgi-installer.html <https://sling.apache.org/documentation/bundles/osgi-installer.html> and https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
>>> Is this really the PID here?
>>> Is there some cleaning in order on the documentation or the implementation side for the OSGi Installer as well?
>>
>> The documentation is correct, configuration is based on PIDs. A
>> component either registers a ManagedService configured with a PID to get
>> the configuration with that PID or you're using a component framework
>> like Declarative Services which does the trick for you.
>>
>> So we're good on that front and in general I think we only have a few
>> places where the usage is wrong. It usually always when you want to have
>> a unique handle for a service.
>>
>>>
>>> I am wondering though, why only the PID is exposed in system/console/services/xxx and not the service id.
>>
>> The first column "Id" is the service ID :)
>>
>> Carsten
>>
>>> Konrad
>>>
>>>
>>>> On 13 Jul 2016, at 12:07, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>
>>>>> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>>> ...We really have to fix our code and get rid of most of the usage of PIDs...
>>>>>
>>>>> And use SERVICE_ID instead when we need a unique key to the service?
>>>>>
>>>> Yes, right
>>>>
>>>> Btw, I fixed the health check core bundle, not sure which others need to
>>>> be fixed. But I guess the list is really short
>>>>
>>>> Regards
>>>>
>>>> Carsten
>>>>
>>>> --
>>>> Carsten Ziegeler
>>>> Adobe Research Switzerland
>>>> cziegeler@apache.org
>>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Reconsider usage of service PID
Posted by Konrad Windszus <ko...@gmx.de>.
Hi Carsten,
I am just wondering because you said the service PID is an implementation detail and being generated automatically by DS (in case the service has been started by DS), if we can always rely on the PID being the component's class name for all Felix version's in the future.
I just don't know how the connection is made between the service and its configuration in case the service is already running (and just a new configuration should be bound).
In case I want to deploy a configuration through the OSGi installer, I want to make sure it gets bound to the right component.
Have you any reference about the format of the PID which must be used here?
In OSGi Core 6.0.0, 10.1.15.106 it just says
public static final String SERVICE_PID = "service.pid"
Service property identifying a service's persistent identifier.
This property may be supplied in the properties Dictionary object passed to the
BundleContext.registerService method. The value of this property must be of type String, String[],
or Collection of String.
A service's persistent identifier uniquely identifies the service and persists across multiple Framework
invocations.
By convention, every bundle has its own unique namespace, starting with the bundle's identifier
(see Bundle.getBundleId()) and followed by a dot (.). A bundle may use this as the prefix of the persistent
identifiers for the services it registers.
Konrad
> On 20 Jul 2016, at 17:42, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> What about usage of PIDs when providing configurations through the repository (as sling:OsgiConfig resources or configuration files as described in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html>) for the OSGi installer. The resource names are supposed to be (at least starting with the) PID, e.g. mentioned in https://sling.apache.org/documentation/bundles/osgi-installer.html <https://sling.apache.org/documentation/bundles/osgi-installer.html> and https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
>> Is this really the PID here?
>> Is there some cleaning in order on the documentation or the implementation side for the OSGi Installer as well?
>
> The documentation is correct, configuration is based on PIDs. A
> component either registers a ManagedService configured with a PID to get
> the configuration with that PID or you're using a component framework
> like Declarative Services which does the trick for you.
>
> So we're good on that front and in general I think we only have a few
> places where the usage is wrong. It usually always when you want to have
> a unique handle for a service.
>
>>
>> I am wondering though, why only the PID is exposed in system/console/services/xxx and not the service id.
>
> The first column "Id" is the service ID :)
>
> Carsten
>
>> Konrad
>>
>>
>>> On 13 Jul 2016, at 12:07, Carsten Ziegeler <cz...@apache.org> wrote:
>>>
>>>> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>>> ...We really have to fix our code and get rid of most of the usage of PIDs...
>>>>
>>>> And use SERVICE_ID instead when we need a unique key to the service?
>>>>
>>> Yes, right
>>>
>>> Btw, I fixed the health check core bundle, not sure which others need to
>>> be fixed. But I guess the list is really short
>>>
>>> Regards
>>>
>>> Carsten
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org
>>>
>>
>>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Reconsider usage of service PID
Posted by Carsten Ziegeler <cz...@apache.org>.
> What about usage of PIDs when providing configurations through the repository (as sling:OsgiConfig resources or configuration files as described in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html>) for the OSGi installer. The resource names are supposed to be (at least starting with the) PID, e.g. mentioned in https://sling.apache.org/documentation/bundles/osgi-installer.html <https://sling.apache.org/documentation/bundles/osgi-installer.html> and https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
> Is this really the PID here?
> Is there some cleaning in order on the documentation or the implementation side for the OSGi Installer as well?
The documentation is correct, configuration is based on PIDs. A
component either registers a ManagedService configured with a PID to get
the configuration with that PID or you're using a component framework
like Declarative Services which does the trick for you.
So we're good on that front and in general I think we only have a few
places where the usage is wrong. It usually always when you want to have
a unique handle for a service.
>
> I am wondering though, why only the PID is exposed in system/console/services/xxx and not the service id.
The first column "Id" is the service ID :)
Carsten
> Konrad
>
>
>> On 13 Jul 2016, at 12:07, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>>> ...We really have to fix our code and get rid of most of the usage of PIDs...
>>>
>>> And use SERVICE_ID instead when we need a unique key to the service?
>>>
>> Yes, right
>>
>> Btw, I fixed the health check core bundle, not sure which others need to
>> be fixed. But I guess the list is really short
>>
>> Regards
>>
>> Carsten
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Reconsider usage of service PID
Posted by Konrad Windszus <ko...@gmx.de>.
What about usage of PIDs when providing configurations through the repository (as sling:OsgiConfig resources or configuration files as described in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html>) for the OSGi installer. The resource names are supposed to be (at least starting with the) PID, e.g. mentioned in https://sling.apache.org/documentation/bundles/osgi-installer.html <https://sling.apache.org/documentation/bundles/osgi-installer.html> and https://sling.apache.org/documentation/bundles/configuration-installer-factory.html
Is this really the PID here?
Is there some cleaning in order on the documentation or the implementation side for the OSGi Installer as well?
I am wondering though, why only the PID is exposed in system/console/services/xxx and not the service id.
Konrad
> On 13 Jul 2016, at 12:07, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> ...We really have to fix our code and get rid of most of the usage of PIDs...
>>
>> And use SERVICE_ID instead when we need a unique key to the service?
>>
> Yes, right
>
> Btw, I fixed the health check core bundle, not sure which others need to
> be fixed. But I guess the list is really short
>
> Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
Re: Reconsider usage of service PID
Posted by Carsten Ziegeler <cz...@apache.org>.
> On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...We really have to fix our code and get rid of most of the usage of PIDs...
>
> And use SERVICE_ID instead when we need a unique key to the service?
>
Yes, right
Btw, I fixed the health check core bundle, not sure which others need to
be fixed. But I guess the list is really short
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Reconsider usage of service PID
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 13, 2016 at 8:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...We really have to fix our code and get rid of most of the usage of PIDs...
And use SERVICE_ID instead when we need a unique key to the service?
-Bertrand