Good idea for the Jira, +1 about that.
Regards
JB
On 08/05/2014 03:12 PM, Peter Kriens wrote:
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 | [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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
