Hi Scott, you might also need to set the property “felix.fileinstall.name” on the configuration dictionary of your component. This should be the mechanism to associate the file with the service/component if I remember right. In one of my components it looks like this: felix.fileinstall.filename = file:/opt/cmis/etc/de.apollon.cmis.server.query.omnfind.cfg
This property is only at the configuration dictionary. You can not see it in the associated FileInstall cfg-file. You can inspect it for your other components for example with the Felix WebConsole. Anyway I can not remember if FileInstall then actually creates a new file for you. You need to give it a try ;) Cheers Sascha > On Dec 15, 2017, at 11:56 PM, Leschke, Scott via osgi-dev > <osgi-dev@mail.osgi.org> wrote: > > Hi Michael, > > Thanks for the response. Yes I’m aware of that mechanism. That’s part of > Karaf’s hot deploy scheme which I’ve used extensively to date. What I need to > do is create new service instances from a UI and have the created services > available immediately, i.e. without the delay, so that the UI can update > without a refresh. > > I know that if you modify a service programmatically, the corresponding .cfg, > if the service has one, is updated. I can’t see anyway to tell the CA > service to persist the new service configuration to a particular location. > For my app, I’ve overridden the org.apache.felix.fileinstall.dir-deploy.cfg > file with my own that causes Karaf to scan a directory hierarchy outside of > the Karaf install hierarchy. That way I don’t have to physically move the > directory structure whenever I update Karaf. > > Anyway, what I’m curious about is whether a .cfg file can/will be associated > with a service after it’s already been created using > createFactoryConfiguration.update(props); ? If I just create one after the > fact, where I want it to reside, I’m curious if it will get associated with > the existing service. Of course I can test this and intend to, I just haven’t > got to that point yet. > > Of course if someone can tell me definitively whether that will work or not, > I won’t have to bother. > > Scott > > From: Michael Wirth [mailto:mwi...@apollon.de <mailto:mwi...@apollon.de>] > Sent: Friday, December 15, 2017 9:00 AM > To: Leschke, Scott; OSGi Developer Mail List > Subject: Re: [osgi-dev] Create instance of factory configuration at runtime > > Hi Scott, > > to point 2) > about 2-3 years ago I had a similar problem. The 'solution' was to create a > configuration file (with the properties) in the > 'felix.fileinstall.dir'-Directory. If it is a Factory the filename should be > <componentname>-<uniqueId>.cfg > After some time (depending on configuration) FileInstall will scan the file, > create the configuration and the service will be instantiated. > > ps. I have just checked, the 'hack' still exists and is live > > Michael > > Am 13.12.2017 um 22:24 schrieb Leschke, Scott via osgi-dev > <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>: > > 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 <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
