Hi, >From the Javadoc of felix-scr-annotations propertyPrivate attribute:
"For the predefined properties service.pid, service.description, service.id, service.vendor, service.bundlelocation and service.factoryPid an AD element will never be created and the propertyPrivate attribute has no effect" I tried it and if I use propertyPrivate=false the metatype entry is generated. However, this raised the question for me if service.description should be used for freely configurable attribute or not. Regards, *Zsoldos Balázs* On Wed, Aug 6, 2014 at 12:45 PM, Balázs Zsoldos <[email protected]> wrote: > I guess the Peter's problem with service.pid was that it is not defined by > the user. It is unique indeed. However, if you have a distributed system, > there is no function in ConfigurationAdmin to create a configuration with > the same service.pid on the other node. A clustered solution cannot be > implemented as an extension (catching events and pushing to other node) but > only be re-implementing ConfigurationAdmin with the replication feature > inside. > > service.pid is assigned to one configuration instance. If someone wants to > replace with another implementation (that registers the same OSGi > services), he/she must also re-configure all dependent components. > > service.pid is is not human-readable. That is where service.description > could help. It is not unique, not even for configurations with the same > factory pid. Description does not mean a short text so it cannot be shown > on a graph for each node. Or it can, but it in the way that if it is too > long, it is cropped. > > For me for now, it does not matter if service.description is unique or > not. The only one importance is that it should be human readable. As soon > as I want to have clustered OSGi containers, I will have the same problems > as Peter has (so I will write a new e-mail :)). > > As OSGi is more and more common in the server side world of Java, I think > many will try to find a solution for these issues. It would be nice if > there was a standard answer. > > Regards, > Balazs > > On Wed, Aug 6, 2014 at 11:55 AM, BJ Hargrave <[email protected]> wrote: > >> service.pid is unique across all configurations belonging to a factory >> pid. Why is that not enough? >> >> The original email was looking for a label that was human readable for a >> UI. And service.description would work for that usage. >> -- >> >> *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/06 05:48 >> Subject: Re: [osgi-dev] Asking for service.pid.label standard >> property >> Sent by: [email protected] >> ------------------------------ >> >> >> >> I do not think it is a label (though it is useful as such) that is >> needed. The service.id is clever but is intended to be human readable >> and has no unique requirements. I frequently have the need for a unique id >> within one factory pid so you can make updates idempotent which you cannot >> do without such an id. >> >> The first use was FileInstall. Since it gets configurations from the file >> system and applies them to Config Admin I needed a way to make sure I did >> not create multiple factory configurations accidentally. The only solution >> I could see was to add an anchor property to the factory configuration so >> that I could see that specific configuration was already created and I just >> needed to update it. >> >> Since then (15 years ago :-( ) I've have many other cases that required >> this same feature, last time was actually last week when I developed a >> distributed Configuration Admin. I've also seen the same pattern being >> invented independently by others. >> >> So I do think we should consider a feature in CM where we can have a >> property that must be unique among all configuration instances belonging to >> a factory pid. It would benefit tools like Web Console, distributed CM, >> file install, etc. if we would have a standard property name for this >> concept. >> >> Kind regards, >> >> Peter Kriens >> >> >> >> >> >> >> On 5 aug. 2014, at 21:23, BJ Hargrave <*[email protected]* >> <[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]* >> <[email protected]>> >> To: OSGi Developer Mail List <*[email protected]* >> <[email protected]>> >> Date: 2014/08/05 09:13 >> Subject: Re: [osgi-dev] Asking for service.pid.label standard >> property >> Sent by: *[email protected]* >> <[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* >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> [attachment "smime.p7s" deleted by BJ Hargrave/Austin/IBM] >> _______________________________________________ >> 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
