Resolution: No Longer Reproducible
Affects Version/s: 7.0.X, Master
Fix Version/s: None
Upon every server startup, a new configuration entry is created in the Configuration_ table on Windows systems if a .config file exists in the osgi/configs folder
Currently, our logic around exporting/importing .config files works differently on Unix and Windows systems and this should be corrected.
1. Start up a Liferay Server on a Windows system, with the liferay.home property configured in portal-ext.properties.
2. Log in as omniadmin and go to Control Panel -> Configuration -> System Settings -> Web API -> CXF Endpoints
(On 7.0.x: Control Panel -> Configuration -> System Settings -> Foundation -> CXF Endpoints)
3. Click the + icon (Add Entry)
4. In the Context Path field, write "/cxf1". Leave the other fields unchanged and click Save.
5. Click on the entry and choose Actions/Export.
6. Place the resulting config file (something called like com.liferay.portal.remote.cxf.common.configuration.CXFEndpointPublisherConfiguration-cae0e2af-8bfa-45c9-b0a5-a3915d531dfb.config) into the server's osgi/configs folder.
7. Restart the server and then go again to Control Panel -> Configuration -> System Settings -> Foundation -> CXF Endpoints.
With each server restart you see more and more lines for the /cxf1 endpoint, one additional entry after each restart.
One config file should be imported only once, the system should check if the database already contains the configuration entry.
Detailed background information:
There have been many tickets opened regarding configuration problems, and there were discussions on how to approach such issues.
One example is the Config admin test plan: https://docs.google.com/document/d/1Z7bSq_xT5pJM2KCd5yXQDsfizWQw2mn3AWNwCqNjOag/edit# where such issues were collected.
Also, there was a discussion here about factory configs where the conclusion was not to touch the code since configs are heavily tied to osgi:
Still, I believe that the behavior that was reported in this current LPS should be corrected: we can not allow Liferay to behave differently on Unix and Windows systems. When I tested my fix it corrected this behavior and brought the same result independently from the op. system used.
Looking in Jira, I found that
LPS-76349 is a very similar issue, but it is not the exact same issue - it produces a stacktrace while this current issue does not.
Also, the LPS-69221 seems to be related, because without the liferay.home property, the behavior is different.