Ok, I now understand you better ... you want an Configuration Admin independent unique id for a factory instance. This is actually a pattern I used a lot myself, I usually call it the 'anchor'. For each factoryPid, the anchor must be unique. This allows you to create a configuration that are idempotent.
Why don't you file a bug on the public OSGi bugzilla? These bugs are discussed
in the EG meetings and can result in a RFP.
Kind regards,
Peter Kriens
On 5 aug. 2014, at 12:35, Balázs Zsoldos <[email protected]> wrote:
> Yes it can be. However, a standard and reserved property name would be good
> as:
>
> - DS and other similar technologies could generate metatype in the way that
> it contains this property always in the first place
> - Web UI could show the label in the table of configuration/component (not
> only on the details view)
> - Graph representations like x-ray could also show this label therefore it
> would be easier to see the state of the system
>
> It is possible to solve this in a custom way with metatype. In case of a
> custom solution, all of the tools have to be also customized to provide
> better information about the system. A standard name would solve this issue,
> by the time every tool would use it.
>
> I do not mean long specifications here. Only a new property in the Constants
> interface with some Javadoc. There should be no check if label is unique, it
> is just a useful property that the user can set always. If there is no value
> provided by the user, the default value can be service.pid.
>
> It is really a nightmare now to configure a system via the UI where there are
> 6-7 components that reference each other and that are instantiated multiple
> times.
>
> Zsoldos Balázs
> Rendszertervező | Software architect
>
>
>
> +36 70 594 9234 | [email protected]
>
> EverIT Kft.
> 1137 Budapest, Katona József utca 17. III. em. 2.
> http://www.everit.biz I [email protected]
>
>
>
> Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt áll,
> a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve az
> általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet címzettje, úgy
> kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az üzenet küldőjét és
> törölje az üzenetet, valamint annak összes csatolt mellékletét a
> rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben tilos az
> üzenetet vagy annak bármely csatolt mellékletét lemásolnia, elmentenie, az
> üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie.
>
>
>
> This message and any attachment are confidential and are legally privileged.
> It is intended solely for the use of the individual or entity to whom it is
> addressed and others authorised to receive it. If you are not the intended
> recipient, please telephone or email the sender and delete this message and
> any attachment from your system. Please note that any dissemination,
> distribution, copying or use of or reliance upon the information contained in
> and transmitted with this e-mail by or to anyone other than the recipient
> designated above by the sender is unauthorised and strictly prohibited.
>
>
>
> On Tue, Aug 5, 2014 at 12:07 PM, Peter Kriens <[email protected]> wrote:
> Isn't this a job for metatype?
>
> Kind regards,
>
> Peter Kriens
>
> On 5 aug. 2014, at 10:11, Balázs Zsoldos <[email protected]> wrote:
>
>> Hi,
>>
>> we use Declarative Services very often. We use the web console and its DS
>> plugin as well.
>>
>> Our experience is that it is easy to configure a system until every
>> Component is instantiated ones. However, as soon as we want to create
>> several configurations for components it is almost impossible to configure
>> the system without creating a spreadsheet and maintain the configuration
>> there as well. In the spreadsheet, we normally create label-service.pid
>> pairs so we can know the aim of an instance without going through all of its
>> references transitively.
>>
>> I would like to ask you to define a standard "service.pid.label" property in
>> the specification. This would be an optional property that could be defined
>> for every configurations. In case this is defined, this could be shown on
>> every management screens that would make configuration much faster. If a
>> reference of a component has service.pid.label defined, that could be shown
>> at the references.
>>
>> service.pid.label would not have any functionality, it would be simply a
>> reserved word so technology implementors (especially webconsole plugin
>> developers) would know that they can use it.
>>
>> Thanks and regards,
>> Zsoldos Balázs
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
