I have a similar requirement as Christian, but it's not really related to fileinstall.
The fact that configs have no "foreign key" makes it difficult to support many use cases. We've come up with the same idea as Christian which is adding more properties in the configuration itself to act as the foreign key. The configuration is often uniquely tied to some other java object which itself may have primary/compound key. By adding the extra data to the configuration at least it is queriable through the config admin api using the filter search. However, this leads to exactly the issue which the "foreign key" is now a mutable which can totally break your relationship. So, I would formalize Christian's idea more around making it possible for configurations to be associated with a foreign key. I think this would solve his issue, as well as mine. - Ray On Apr 5, 2015 7:31 AM, "Neil Bartlett" <njbartl...@gmail.com> wrote: > 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
