I think that I figured it out. I think that it is a configuration issue in the stock configuration of Karaf Container (apache-karaf-4.0.10.tar.gz).
etc/org.apache.karaf.features.cfg contains: #configCfgStore=true which I think means that the default setting is for the features service to write feature configurations to the configuration directory, etc. etc/config.properties contains: felix.fileinstall.dir = ${karaf.etc} which means that the fileinstall service will monitor the etc directory for changes. I believe that the combination of these two settings causes the following: - the features service sends the configuration to configuration admin (first config) - the features service writes the configuration to etc - the fileinstall service sees the new file in etc - the file install service write the configuration to configuration admin (second config) Setting configCfgStore=false fixes everything. So in the end, the two issues I asked about in my original email were related. The second issue was causing the first. On Thu, Nov 9, 2017 at 10:14 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Yes, please ! > > Thanks, > Regards > JB > > On 11/09/2017 04:12 PM, Tim Moloney wrote: > >> Should I create a new issue for this in JIRA? >> >> >> On Wed, Nov 8, 2017 at 8:58 AM, Tim Moloney <tim.molo...@gmail.com >> <mailto:tim.molo...@gmail.com>> wrote: >> >> Yes, the config blocks start like >> >> <config name="/ServiceFactory/-/InstanceName/"> >> >> No, I don't start with any custom service configuration files in >> etc. Only >> the ones that come with Karaf. After running, however, configuration >> files >> for each of the services are created in etc (see the last paragraph >> in my >> original email). >> >> I did notice that if I comment out the config blocks in the features >> repository, a service will get configured only once if I >> - start with a service's configuration file in etc before starting >> Karaf >> - copy a service's configuration file to etc after starting Karaf >> >> If I understand Karaf correctly, this means that the fileinstall >> capability >> is working correctly and that its the feature capability that is >> sending >> configurations to configadmin twice. >> >> Thanks, >> Tim >> >> On Tue, Nov 7, 2017 at 11:57 PM, Jean-Baptiste Onofré < >> j...@nanthrax.net >> <mailto:j...@nanthrax.net>> wrote: >> >> Hi Tim, >> >> the <config/> contains a config factory right ? Something like >> pid-foo ? >> >> Do you have the corresponding cfg file in the etc folder ? >> >> Regards >> JB >> >> >> On 11/08/2017 12:58 AM, Tim Moloney wrote: >> >> I'm upgrading an application from Karaf 2.3.3 to 4.0.10 and >> have it >> so that everything compiles and loads correctly. >> Unfortunately, the >> services are getting configured twice. >> >> The app configures its services using named <config> blocks >> in the >> features repository. With Karaf 4.0.10, the service factory's >> update(servicePid, dictionary) method is getting called twice >> with >> the same config block (dictionary) but with different >> servicePids. >> >> Any thoughts on how to get around this issue? >> >> On a related note, after the services are configured, a new >> file is >> created in the etc directory named after the config block >> name. This didn't happen with Karaf 2.3.3. Is there a >> configuration so >> these files aren't written? >> >> Thanks, >> Tim >> >> >> -- Jean-Baptiste Onofré >> jbono...@apache.org <mailto:jbono...@apache.org> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >