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

Audience Targeting portlet has wrong staticResourcePath when portal.proxy.path is set

    Details

    • Type: Bug
    • Status: Closed
    • Resolution: Duplicate
    • Affects Version/s: 6.2.2 CE GA3
    • Fix Version/s: None
    • Component/s: Internal
    • Labels:
      None

      Description

      Steps:
      1. Set portal.proxy.path=/portal in portal-ext.properties
      2. Apply workaround from Bejond Shao's comment from LPS-49447 in order to make Liferay start up properly at all
      3. Put Audience Targeting 1.1 to Liferay's deploy directory
      4. Start the portal
      5. Log in as Administrator, go to control panel
      6. Go to some site's administration
      Result:
      1. First sign of a problem is the fact that the Audience Targeting portlet's icon is broken. This is due to a faulty src attribute of the icon's img tag: /portal/portal/o/content-targeting-web/icons/icon.png instead of /portal/o/content-targeting-web/icons/icon.png (note the duplicated proxy path)
      2. Icon aside, when you go to the portlet itself and then try to add a segment the portlet is unoperable due to javascripts not loading (due to them being referenced by a wrong path).
      Possible cause?

      The problem, at first glance, lies in the PortletImpl.getStaticResourcePath() method, which concatenates proxyPath (/portal) with the result of getContextPath() method (/portal/o/content-targeting-web).

      By comparison to a similar getStaticResourcePath method in ThemeImpl I came to conclusion that it's the getContextPath() method where the root of the problem lies, because in the ThemeImpl the proxy path is not contained in context path.

      Going further I found out that the context path is retrieved from a ServletContext from ServletContextPool. This was where I hit the wall, not being able to track down what creates the faulty servletContext which is later put into the ServletContextPool in the first place.

      workaround

      A quick and dirty workaround may be to replace this line in getStaticResourcePath():

      		if (!getPortletApp().isWARFile()) {
      			

      with this:

      		if (!getPortletApp().isWARFile() || contextPath.startsWith(proxyPath)) {
      

      I think it may lead to some unexpected behaviour if proxy path equals o or some portlet's name, but that seems like a rather cornery case and it gets the job done, i.e. makes Audience Targeting work.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jorge.diaz Jorge Diaz
                Reporter:
                michal.mela Michał Mela
                Participants of an Issue:
                Recent user:
                Esther Sanz
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  3 years, 33 weeks, 3 days ago

                  Packages

                  Version Package