-
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
-
Branch Version/s:7.2.x, 7.1.x, 7.0.x
-
Backported to Branch:Committed
-
Fix Priority:3
-
Git Pull Request:
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.
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.
- relates
-
LPS-116218 Fix OSGI config DB entry duplication with symbolic link
- Closed