@BJ Hargrave: Thank you! service.description could do the thing.
I will add that to every component that I developed. It might be useful to add this property automatically to the generated metatype information of every component (DS). Description can be a long text in theory. If I have a screen for configuration management, I have to open the configuration to see its description. If I understand well, Peter uses 'anchor' property to be able to provide a short description (label) for his component instances. A short text can be well visualized on management screens (e.g.: a column on the configadmin page of webconsole or on the node of a graph). For now, I am satisfied with service.description. Thanks again! *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 9:23 PM, BJ Hargrave <[email protected]> wrote: > Why isn't this just service.description? It's value can certainly be > unique for every registered service and tools can display it (or some > abbreviation if long). > > I am not sure I see the need for another human readable "label" on a > service registration. > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> > *[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > From: Peter Kriens <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Date: 2014/08/05 09:13 > Subject: Re: [osgi-dev] Asking for service.pid.label standard > property > Sent by: [email protected] > ------------------------------ > > > > 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]* > <[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]* <[email protected]> > > *EverIT Kft.* > 1137 Budapest, Katona József utca 17. III. em. 2. > *http://www.everit.biz* <http://www.everit.biz/> I *[email protected]* > <[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]* > <[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]* > <[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]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List > *[email protected]* <[email protected]> > https://mail.osgi.org/mailman/listinfo/osgi-dev > [attachment "smime.p7s" deleted by BJ Hargrave/Austin/IBM] > _______________________________________________ > 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
