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

Liferay.Language.get("key") method is not replaced with actual value when Javascript.fast.load=true

    Details

      Description

      Update 07/07/2017:
      I worked with Sam today and we have a very good guess where the root cause come from:
      So when Javascript.fast.load is turned on, the the filtering will go through comboServlet, and the comboServlet is in Portal context, which means lit will not be able to retrieve context of custom-portlet (ie. the custom-portlet instance of LanguageFilter, as well as the _portletConfig), which causes the issue of 03.
      However it is still unclear which exact piece of code is the root cause. And potentially, there will be a big change for comboServlet to add support to pass in custom-portlet context.

      -----------------------------------
      -----------------------------------
      -----------------------------------
      Hi SMEs,
      I need help trying to determine the root cause for this issue.

      6.2 portlet in WAR file form can be deployed to master/dxp, but there will be a problem:
      In the JavaScript, Liferay.Language.get("key") method will not be replaced with actual value when Javascript.fast.load=true, ie the js fast load is turned on.

      Here are the things we found during debugging:

      01. There is no such issue when this portlet is deployed to 6.2.

      02. A generic 7.0 module project has no such issue when deployed to master/dxp.

      03. The reason it is not replacing with actual language value is that, LanguageFilter.translate()the LanguageFilter is missing _portletConfig, ie _portletConfig is null.

      04. The reason it is missing _portletConfig is that, it is using the wrong LanguageFilter instance. when portal starts, portal will instantiate one instance of LanguageFilter, and the custom-portlet will also instantiate an instance of LanguageFIlter with _portletConfig. When trying to process the filter, it is using the Portal's LanguageFilter instance.

      05. The reason it is using portal's LanguageFIlter instance is that, the ClassLoader(see in InvokeFilter.doFilter()) is portal's LanguageFilter classLoader.

      06. On 6.2, when LanguageFIlter.processFIlter() is called, the ClassLoader gets passed in is custom-portlet's.

      07. On 7.0, when LanguageFIlter.processFIlter() is called, the ClassLoader gets passed in is portal's.

      08. On 7.0, when javascript fast load is turned off, after processFilter() in LanguageFilter.processFilter() returns, the ClassLoader will be changed to custom-portlet's.

      09. On 7.0, when javascript fast load is turned on, after processFilter() in LanguageFilter.processFilter() returns, the ClassLoader will not be changed to custom-portlet's.

      10. On 7.0, when javascript fast load is turned off, the processFilter() in LanguageFilter.processFilter() will eventually invoke LanguageFIlter again with different filterChain.

      11. On 7.0, when javascript fast load is turned on, the processFilter() in LanguageFilter.processFilter() will no invoke LanguageFIlter again.

      Images attached are on 7.0, when javascript fast load is turned off:

      Unable to render embedded object: File (Selection_014.png) not found. Unable to render embedded object: File (Selection_015.png) not found.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 28 weeks, 4 days ago