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

As a user, I would like to have a GUI to update the HTTP header response properties in system.properties



      Currently, the HTTP header response properties are set as system.properties in https://github.com/liferay/liferay-portal/commit/b1443e8bf15a8fa0955edd8b971820826ef6e3af.

      We want to create a GUI for users to be able to update these values based on the comments from the pull request (https://github.com/brianchandotcom/liferay-portal/pull/42696#issuecomment-242897288). In order to do so, we would need to move these properties back to portal.properties.

      I had a discussion with Minhchau Dang regarding the why these properties were moved from portal.properties to system.properties to begin:

      "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.


      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.


      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."




            support-lep@liferay.com SE Support
            jonathan.mak Jonathan Mak
            Recent user:
            Kiyoshi Lee
            Participants of an Issue:
            0 Vote for this issue
            0 Start watching this issue




                Version Package