[
https://issues.apache.org/jira/browse/FELIX-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-5165.
------------------------------------
Resolution: Cannot Reproduce
Assignee: Guillaume Nodet
I think this does not apply anymore with the recent changes in fileinstall
where both untyped and typed config are handled the same way.
> Fileinstall: OSGi config values not exposed to webconsole are lost upon
> saving because config manager overwrites instead of merge with internal set.
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-5165
> URL: https://issues.apache.org/jira/browse/FELIX-5165
> Project: Felix
> Issue Type: Bug
> Reporter: munene kiruja
> Assignee: Guillaume Nodet
>
> Supposing you have settings you prefer to keep away from webconsole's easy
> access. When you update other settings on the webconsole, it asks configadmin
> to update itself. Config admin takes the settings overwrites what it had. The
> service loses the values that are hidden until the next container restart (or
> similar event) when it rereads the file.
> Perhaps there might be a case for this behavior, so maybe there should be a
> setting to choose preference.
> In our case, we have a third party OSGi container that uses Apache
> Fileinstall and Webconsole but their custom config admin (which does not
> merge changes upon Update(Dictionary props);. Apache's own also does not. We
> propose making Fileinstall update configadmin from file (as it is the one
> that can notice such a discrepancy.
> Its ConfigInstaller.setConfig method already does all the work of checking
> for differences, however in respect to the new .config format for
> configuration, it has a bug - namely - when the values of the map are arrays,
> the comparison is faulty (based on addresses of the arrays instead of the
> contents). This is easy to fix.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
