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

• Type: Bug
• Status: Closed
• Resolution: No Longer Reproducible
• Affects Version/s: 7.0.X, Master
• Fix Version/s: None
• Component/s: Portal Configuration, Web Services
• Labels:
  • ee-ts
• Fix Priority: 3
• OS:
  Windows 7, Windows 8, Windows 10
• Git Pull Request: https://github.com/ericyanLr/liferay-portal/pull/165

Description:
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.

Reproduction Steps:
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.

Actual Results:
With each server restart you see more and more lines for the /cxf1 endpoint, one additional entry after each restart.

Expected Results:
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:
https://issues.liferay.com/browse/LPSP-285?focusedCommentId=1206124&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1206124

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.