OSGI config DB entry duplication with symbolic link

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.2.X, Master
• Fix Version/s: 7.0.0 DXP FP93, 7.0.10.14 DXP SP14, 7.0.X, 7.1.10 DXP FP18, 7.1.10.5 SP5, 7.1.X, 7.2.10 DXP FP6, 7.2.X, 7.3.3 CE GA4, 7.3.10 DXP GA1, Master
• Component/s: Core Infrastructure, Portal Services > Component Management > Module Framework (OSGi)
• Labels:
  • ee-ts
  • liferay-dxp-70-sp14
  • liferay-dxp-71-sp5
  • liferay-fixpack-de-93-7010
  • liferay-fixpack-dxp-18-7110
  • liferay-fixpack-dxp-6-7210
• Branch Version/s:
  7.2.x, 7.1.x, 7.0.x
• Backported to Branch:
  Committed
• Fix Priority: 3
• Git Pull Request: https://github.com/shuyangzhou/liferay-portal/pull/9101

When symbolic link is enabled on a bundle, OSGI config database entries are getting duplicated.

Steps to reproduce:

1. Create a symbolic link to your root folder of Liferay (ln -s liferay-dxp-7.2.10-ga1 live)
2. Change liferay.home in portal-ext.properties to put home Liferay folder with /live (and not the real path)
3. Start Liferay
4. Check Configuration_ table in the database
5. Stop and start Liferay again
6. Check the Configuration_ table again

Expected result: the number of rows in the Configuration_ table remains unchanged
Actual result: each entry gets inserted again

Cause:

When liferay.home is a symbolic link, in modules/third-party/org-apache-felix-fileinstall/src/main/java/org/apache/felix/fileinstall/internal/ConfigInstaller.java the props of the configuration will be null, thus config.update(ht) will be called at every portal startup.

On the other hand, when liferay.home is a proper file, props is properly initialized by the time the portal is started a second time.

ConfigInstaller.java

        Dictionary<String, Object> props = config.getProperties();
        Hashtable<String, Object> old = props != null ? new Hashtable<String, Object>(new DictionaryAsMap<>(props)) : null;
        if (old != null) {
        	old.remove( DirectoryWatcher.FILENAME );
        	old.remove( Constants.SERVICE_PID );
        	old.remove( ConfigurationAdmin.SERVICE_FACTORYPID );
        }

        if(!_equals(ht, old))
        {
            ht.put(DirectoryWatcher.FILENAME, toConfigKey(f));
            if (old == null) {
                Util.log(context, Logger.LOG_INFO, "Creating configuration from " + pid[0]
                        + (pid[1] == null ? "" : "-" + pid[1]) + ".cfg", null);
            } else {
                Util.log(context, Logger.LOG_INFO, "Updating configuration from " + pid[0]
                        + (pid[1] == null ? "" : "-" + pid[1]) + ".cfg", null);
            }
            config.update(ht);

The reason behind this is that in ConfigurationPersistenceManager._verifyDictionary() the path of configFile will contain the symbolic link and it will not be detected, that the configuration has been saved previously. The link should be resolved to the actual file.