Details

      Description

      They were initially moved to system.properties for the following reasons:

      Why were these moved to system.properties instead of portal.properties?

      Liferay modifies the web.xml of every Liferay plugin WAR to include a reference to InvokerFilter and causes InvokerFilter to be used on every request. This is still true in master.

      https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/tools/deploy/BaseDeployer.java#L659
      https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/tools/deploy/BaseDeployer.java#L2188
      https://github.com/liferay/liferay-portal/blob/master/portal-impl/src/com/liferay/portal/tools/deploy/BaseDeployer.java#L2079-L2081

      It's possible for a request to something other than Liferay to cause InvokerFilter to run (for example, a request for a theme resource contained in a theme WAR) before Liferay is initialized. When it does this and InvokerFilter calls any methods on a class that has a static initializer referencing PropsUtil, a class initialization error will occur. Subsequently, every request throws the ClassNotFoundException, which makes pretty much all of Liferay unusable.

      https://github.com/liferay/liferay-portal/blob/master/portal-kernel/src/com/liferay/portal/kernel/servlet/filters/invoker/InvokerFilter.java#L78-L80
      https://github.com/liferay/liferay-portal/blob/master/portal-kernel/src/com/liferay/portal/kernel/servlet/filters/invoker/InvokerFilter.java#L319-L320

      If you attempt to restart the server to address the issue, it's possible for a different request to cause the same problem again, forcing yet another restart. You have to keep doing this until you finally get lucky enough for nothing to make a request to Liferay until Liferay has initialized.

      The simplest way to address this was to switch to SystemProperties, which is partially initialized when the code is called and is fully initialized with the values in system.properties and system-ext.properties once the portal is initialized.

      There is still a bug associated with the approach (if the first request goes to a plugin, it no longer uses the value specified in system-ext.properties, and to work around it, you actually have to specify things via -Dproperty.name=property.value properties), but at the time, it was preferred over moving the static initializer block.

      All these challenges would need an additional implementation in order to be able to create a UI for it. That's the goal of this subtask

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              support-lep@liferay.com SE Support
              Reporter:
              jorge.ferrer Jorge Ferrer
              Recent user:
              Jonathan Mak
              Participants of an Issue:
              Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Days since last comment:
                4 years, 4 weeks, 3 days ago

                  Packages

                  Version Package