Hi Am 06.08.2014 um 17:18 schrieb Balázs Zsoldos <[email protected]<mailto:[email protected]>>:
Hi, From the Javadoc of felix-scr-annotations propertyPrivate attribute: "For the predefined properties service.pid, service.description, service.id<http://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. This is really only about the metatype. If the Felix SCR @Property annotation is used for any of the properties it will end in the SCR descriptor. The propertyPrivate attribute is used to decide whether the property is also added to the Metatype descriptor. The idea is that you might want want to define e.g. the service.description but you don't want configuration to overwrite it. Explicitly setting propertyPrivate=false allows you to overwrite this default assumption. Hope this helps Regards Felix Regards, Zsoldos Balázs On Wed, Aug 6, 2014 at 12:45 PM, Balázs Zsoldos <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> office: +1 386 848 1781<tel:%2B1%20386%20848%201781> mobile: +1 386 848 3788<tel:%2B1%20386%20848%203788> From: Peter Kriens <[email protected]<mailto:[email protected]>> To: OSGi Developer Mail List <[email protected]<mailto:[email protected]>> Date: 2014/08/06 05:48 Subject: Re: [osgi-dev] Asking for service.pid.label standard property Sent by: [email protected]<mailto:[email protected]> ________________________________ I do not think it is a label (though it is useful as such) that is needed. The service.id<http://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]<mailto:[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]<mailto:[email protected]> office: +1 386 848 1781<tel:%2B1%20386%20848%201781> mobile: +1 386 848 3788<tel:%2B1%20386%20848%203788> From: Peter Kriens <[email protected]<mailto:[email protected]>> To: OSGi Developer Mail List <[email protected]<mailto:[email protected]>> Date: 2014/08/05 09:13 Subject: Re: [osgi-dev] Asking for service.pid.label standard property Sent by: [email protected]<mailto:[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]<mailto:[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<tel:%2B36%2070%20594%209234> | [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[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]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[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]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected]<mailto:[email protected]> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
