Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-107027

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

    Details

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            peter.petrekanics Peter Petrekanics
            Reporter:
            peter.petrekanics Peter Petrekanics
            Participants of an Issue:
            Recent user:
            Peter Petrekanics
            Engineering Assignee:
            Peter Petrekanics
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Days since last comment:
              15 weeks, 1 day ago

                Packages

                Version Package