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 <ch...@die-schneider.net> 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
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
