Hey Scott, 2) is about the Felix FileInstall component (which is also used in Karaf). I am not sure if FileInstall ever initially creates a new File for a configuration but if it can you might need to set an additional property in the configuration: “felix.fileinstall.filename”
For example in my Karaf instance it looks like this for a non-factory config: felix.fileinstall.filename = file:/opt/cmis/etc/de.apollon.cmis.server.query.omnfind.cfg (Note that this property is never stored in the *.cfg file itself. You can only inspect it directly in the configuration dictionary (for example in Felix WebConsole -> Status -> Configuration) Different factory cfg files can be distinct by a ‘-‘ and an ID like “org.my.component.name-myfactorycfg1.cfg” Cheers Sascha > On Dec 14, 2017, at 4:24 AM, Leschke, Scott via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > Hey Tim, > > Thanks for this. Yes that worked. I recall seeing something about this a > number of months ago but didn’t pay much attention since it didn’t apply to > me at the time. Not sure why I didn’t think to give that a try though. > > Two additional questions for anybody who cares to answer. > > 1) If “?” isn’t used, what would the location argument look like? Is it > like a bundle symbolic id, with wildcards perhaps? It’s unclear to me how > this would be used even if you wanted to. > 2) Now for a Karaf question to any/all takers. When a service instance > is created this way, is there a way to associate a .cfg file with it so that > the service configuration will persist across Karaf upgrades? I know that if > a Configuration record is updated, the service’s corresponding .cfg file is > updated, but if you create a new service, you don’t get a .cfg file. > > Scott > > From: Tim Ward [mailto:tim.w...@paremus.com <mailto:tim.w...@paremus.com>] > Sent: Saturday, December 09, 2017 3:04 AM > To: Leschke, Scott; OSGi Developer Mail List > Subject: Re: [osgi-dev] Create instance of factory configuration at runtime > > Hi Scott, > > That does work, but Configuration Admin has an old feature called location > binding. This feature prevents a configuration being delivered to bundles > other than the bundle with the specified bundle location. > > The one-arg version of createFactoryConfiguration that you’re using defaults > the bundle location to the location of the bundle which got the > ConfigurationAdmin service instance that you’re using. This is almost never > the correct location as it usually means only the management bundle can see > your configuration. > > The location binding behaviour is so annoying that the general recommendation > is to disable it by using the two arg versions of Config Admin methods with a > wildcard location binding (a “?”). > > My guess is that the two arg version will give you what you’re looking for. > > Tim > > Sent from my iPhone > > On 9 Dec 2017, at 00:36, Leschke, Scott via osgi-dev <osgi-dev@mail.osgi.org > <mailto:osgi-dev@mail.osgi.org>> wrote: > > How does one create a new instance of a factory configuration > programmatically? > > I thought it was like > > ConfigurationAdmin ca; > ca.createFactoryConfiguration(“my.configuration.pid”).update(newServiceProps); > > but that doesn’t seem to work for me. > > Thanks in advance, > > Scott > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev>_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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
