On Mon, Apr 6, 2015 at 12:00 PM, Jean-Baptiste Onofré <[email protected]> wrote:
> +1 > > Regards > JB > > On 04/06/2015 03:30 PM, BJ Hargrave wrote: > >> 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. > > So to be clear, you mean something like: my.primary.key.property.XYZ=value-ignored and then: (&(service.factoryPid=whatever.the.pid.is)(my.primary.key.property.XYZ=*)) ... that might work as a temporary solution :( However it means you could never localize that key in the UI! - Ray > 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_ <http://www.osgi.org/>_ >> [email protected]_ <mailto:[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 >> >> > -- > 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 > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
