Seem like you just need a convention where you put the human readable/pretty name in a key of the configuration and then you can find it with listConfigurations if you need to. It is also in the configuration when MSF is called. The generated pid of the configuration is just the primary key. You can also look up the configuration using a secondary key (the pretty name) if you need. --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Christian Schneider <[email protected]> To: Neil Bartlett <[email protected]>, OSGi Developer Mail List <[email protected]> Date: 2015/04/06 05:29 Subject: Re: [osgi-dev] Proposal named pids for ManagedServiceFactory Sent by: [email protected] Hi Neil, I agree that a create operation does not make sense in this context. What about this: Configuration getFactoryConfiguration(String factoryPid, String pid) It could also be named createOrGetFactoryConfiguration. Like for regular confiurations it would retrieve an existing configuration or create a new one if non exists. The impl could either use the pid directly as the pid of the configuration or create a pid by concatenating factoryPid-pid like fileinstall does. Raymond explained the use case in a little more general way. What I need is indeed some kind of foreign key to identify the configuration with a human readable identifier that can be related to some other known name. In my data source example from pax-jdbc the idea is to reflect the name of the DataSource in the identity of the configuration. At the same time there should be one service that watches for such named configurations and creates a datasource with that name. So the problem with current config admin is that each ManagedService and ManagedServiceFactory solve some part of my problem but not all of it. ManagedServiceFactory allows me to watch for a whole set of configurations but does not allow me to name each configuration on creation. ManagedService on the other hand allows me to use a nice name but does not allow to listen to a whole set of configurations. One concrete technical use case in relation to file install would be that we could create a file when the above getFactoryConfiguration(String factoryPid, String pid) is called. Currently we have the problem that the user can not give the configuration a good name when he creates it using the spec interface. So we do not have a good way to determine a name. Christian Am 05.04.2015 um 13:31 schrieb Neil Bartlett: > Hi Christian, > > Unfortunately if you do this then you run into the same problem we have with non-factory configurations: what if somebody has already created a record for the PID you requested? Notice that for non-factory configs there is no “createConfiguration” method in ConfigAdmin, only “getConfiguration” which actually has the semantics of “create or get existing”. > > What is the use case for this anyway? Bear in mind that the -name suffixes are purely an artifice of FileInstall, because it relies on a flat properties format and most (all?) filesystems disallow multiple files with the same name. Other management agents use a single non-flat file, such as XML or JSON, and so don’t need this trick. > > Neil > > >> On 5 Apr 2015, at 09:57, Christian Schneider <[email protected]> wrote: >> >> There is a quite typical pattern I see in many uses of ManagedServiceFactory in karaf. >> The config is created as a file with a name like etc/<factoryPid>-<name>.cfg. >> >> I think this is a good thing as for many types of configs the naming makes sense. For example in pax jdbc it is used by convention as the name of the data source. >> >> The problem is that in ConfigurationAdmin there is only one way to create a config for a factory: >> Configuration createFactoryConfiguration(java.lang.String factoryPid) >> >> The real id of the config is created as a random string. >> So it is not possible to know the name given from the spec perspective. In pax jdbc and many other cases we worked around this by creating an additional property for this name. This is a bit redundant though. Even more the file name can differ from this property value and so mislead the user. >> >> I know that the config admin spec does not look into mapping to files but it would make sense to provide all data to make the mapping easy. >> >> So my proposal is to allow to add an id in the creation: >> Configuration createFactoryConfiguration(String factoryPid, String name) >> >> The full config pid could then match the file name we use above. >> >> This change would make it much easier t map between the files and the configs. Config admin could the also add the name/id as a property to the config. >> >> What do you think? >> >> Christian >> _______________________________________________ >> 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
