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é <[email protected]>
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 <[email protected]
>> <mailto:[email protected]>> 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é <
>> [email protected]
>> <mailto:[email protected]>> 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é
>> [email protected] <mailto:[email protected]>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
