Uploaded image for project: 'Hippo Site Toolkit 2'
  1. Hippo Site Toolkit 2
  2. HSTTWO-3516

Container resources (webfiles, repository binaries and static webapp files) in case of submounts can incorrectly reset the 'rendering mount' in the channel mngr

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.2.0
    • Component/s: None
    • Similar issues:

      Description

      Since 10.0, binaries (webfiles, repository binaries and static webapp files) are also matched via an hst mount and sitemap (instead of skipped by hst matching like was done before by prefix/postfix exclusions).
      We call webfiles, repository binaries and static webapp files in the HST all 'container resources'. Container resources are always loaded relative to the webapp and not to the mountpath: org.hippoecm.hst.core.linking.HstLink#isContainerResource says:

          /**
           * <p>
           *     When {@link #isContainerResource()} returns <code>true</code>, the resulting URL will be webapp relative and not
           *     relative to {@link Mount#getMountPath()}
           * </p>
           * <p>
           *     When {@link #isContainerResource()} returns <code>false</code>, the resulting URL <b>WILL</b> include the
           *     {@link Mount#getMountPath()} after the webapp relative part (context path).
           * </p>
           * @return <code>true</code> when the HstLink represents a container resource, like a repository binary, a web file
           * or a static css file served by the container.
           */
          boolean isContainerResource();
      

      However, this currently results in the following (BIG) problem:
      Whenever a submount is rendered in the channel manager, for example /sub-hap, then, in the HstDelegateeFilterBean we set the matched mount on the HTTP session. Then during processing (for example in page composer rest endpoint), we can take the 'currently edited mount' from the HTTP session. However, when concurrently container resources are requested (css, js, webfiles, repository binaries, etc), then always the root mount is matched for those requests, and the http session gets the root mount set as editing mount.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                adouma Ate Douma
                Reporter:
                aschrijvers Ard Schrijvers
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: