This article covers a Bloomreach Experience Manager version 11. There's an updated version available that covers our most recent release.

Mount Matching

A Mount is the mapping between some URL prefix and a (sub)site. A Mount directly below the virtual host has the mandatory name hst:root, and is equivalent to “/” . This Mount matches every URL. When the root Mount contains a child node who's name is equal the next path segment in the URL, this Mount is matched. A path segment is the part of a URL between two slashes. The matched child mount can again contain child mounts: the mount configuration is a composite (tree) structure, where any mount can contain child mounts. For matching, the deepest Mount that matches the URL is matched and used during further request processing.

Assume the following configuration for development:

+ hst:hst             [hst:hst]
   + hst:hosts        [hst:virtualhosts]
     + localhost      [hst:virtualhost]
       + hst:root     [hst:mount]
         + de         [hst:mount]
         + fr         [hst:mount]
         + nl         [hst:mount]


Now the follow URLs map to the following Mounts (assuming the contextpath empty):

1. http://localhost:8080/home --> hst:root
2. http://localhost:8080/news/2011 --> hst:root
3. http://localhost:8080/fr --> fr
4. http://localhost:8080/fr/news --> fr
5. http://localhost:8080/de --> de

Because the Mount configurations is a composite pattern, the following configuration is also possible:

+ hst:hst             [hst:hst]
   + hst:hosts        [hst:virtualhosts]
     + localhost      [hst:virtualhost]
       + hst:root     [hst:mount]
         + de         [hst:mount]
         + fr         [hst:mount]
         | + sub1     [hst:mount]
         | + sub2     [hst:mount]
         + nl         [hst:mount]

In the example above, there are two separate extra subsites for the French mount fr. Hence the following URLs would map as follows:

1. http://localhost:8080/fr --> fr
2. http://localhost:8080/fr/news --> fr
3. http://localhost:8080/fr/sub1 --> fr/sub1
4. http://localhost:8080/fr/sub2/news --> fr/sub2

Mounts have some mandatory and optional configuration properties. A Mount inherits its properties from its parent Mount, and the root Mount inherits its properties from the Virtualhost it belongs to.

On Mount nodes you only need to configure properties that are different from parent configuration nodes.

The most important configuration property of a Mount is the hst:mountpoint. This is the absolute JCR path to the node that contains the content and the configuration for this Mount (aka site). Other important properties are listed below. Note that these are only the most important properties.

Property name





The location of the hst:site containing information about the content and configuration for this Mount



Location of the hst:channel node containing channel information for the mount. Without this property, the mount won't show up in the channel manager.



The sitemap item path of the home page when the URL ends at exactly the Mount, for example when the URL is /.

The property can also be a sitemap item refId of the home page, instead of a sitemap item path. HST Linking Component will look up a SiteMapItem by refId first, and it will look up a SiteMapItem by path if not found. For example, a mount of the French locale has ' hst:homepage = "home"' and its sitemap has ' accueil' sitemap item only (without 'home' sitemap item) which has ' hst:refId = "home"', then HST Linking Component will create a link to ' accueil' sitemap item by resolving it based on refId. If not found by refId, it will look up a sitemap item by resolving it simply based on path.



The locale information for this Mount: this locale is also set on the HttpServletRequest and thus using I18n ResourceBundles can be used without further having to set the Locale.



The link to create when the HST cannot create a link for some document.

The property can also be a sitemap item refId of the pagenotfound page, instead of a sitemap item path.
HST Linking Component will look up a SiteMapItem by refId first, and it will look up a SiteMapItem by path if not found.
For example, a mount of the French locale has 'hst:pagenotfound = "error"' and its sitemap has ' erreur' sitemap item only (without 'error' sitemap item) which has 'hst:refId = "error"', then HST Linking Component will create a link to ' erreur' sitemap item by resolving it based on refId. If not found by refId, it will look up a sitemap item by resolving it simply based on path.



The type of the Mount. Default it is live.



Extra (sub)type information. Can be used to give the HST extra hints to prefer to link to some Mount in case of cross domain linking. In case of cross domain linking, the HST prefers Mounts that have most hst:types in common with the current Mount.



The pipeline to use for the request processing



This property has been deprecated in Hippo 10.



Whether the hst:mountpoint points to a hst:site. Only use false for certain REST mounts. Also see REST Mount Property ismapped.



The name of the mount which you can use to create a link for, regardless of the name of the mount.

hst:authenticated / hst:roles / hst:users

See Delivery Tier Authorization Configuration

Securing a Mount

The hst:homepage property can best contain a valid refId value pointing to its homepage sitemap item. So, you can have the same value for both English site and French site by configuring the same refId value instead of using different sitemap item paths. Alternatively, it is also possible to have the hst:homepage property for a French site to be accueil instead of home. This can be very nicely configured per Mount to support language per site and per channel.

It is also possible to configure a Mount to be secured, in other words, that you need to authenticate when you want to access a URL for that Mount.

The hst:channelpath points to a hst:channel node, that contains information about the channel. This information is needed by the channel manager, and at the same time, available for a hst Mount through getChannelInfo(), see the code snippet below. The repository configuration is as follows:


+ hst:hst
  + hst:configurations
  + hst:blueprints
  + hst:channels
  |  + example
  |    - hst:channelinfoclass = org.example.channels.WebsiteInfo
  |    - hst:name = Example
  |    + hst:channelinfo
  + hst:sites
  + hst:hosts
     + dev-localhost
        + localhost
          + hst:root
            - hst:channelpath = /hst:hst/hst:channels/example
            - hst:mountpoint = /hst:hst/hst:sites/example

Example of a HstComponent that uses the WebsiteInfo interface to access channel properties stored on the hst:channelinfo node

public class Header extends BaseHstComponent {
    public void doBeforeRender(final HstRequest request,
                               final HstResponse response)
                                      throws HstComponentException {
        final Mount mount =
        // WebsiteInfo is an interface that extends from
        final WebsiteInfo info = mount.getChannelInfo();

Also see the chapter Channel Manager for more info.
As already mentioned, the hst:mountpoint contains the information about which (sub)site must be used for the Mount. In general a hst:mountpoint always points to a node of type hst:site below the /hst:hst/hst:sites. There is a special case, mainly for REST-interfaces where this is not needed. Thus, for example, the hst:root mount has a hst:mountpoint to /hst:hst/hst:sites/example and the fr mount to /hst:hst/hst:sites/example-fr. The nodes example and exmple-fr must be of type hst:site. The hst:site nodes contain a property hst:content that is the absolute JCR path to the content for the site. 
The hst:site nodes for the hosts configuration with only one site named example results in :

+ hst:hst
  + hst:blueprints
  + hst:channels
  + hst:configurations
  + hst:hosts
  |  + dev-localhost
  |    + hst:root
  |      - hst:mountpoint = /hst:hst/hst:sites/example
  |      - hst:channelpath = /hst:hst/hst:channels/example
  + hst:sites
  |  + example        
  |     - hst:content = /content/documents/example
  + content
      + documents
      |  + example
      + gallery
      + assets
      + attic      

If to the above configuration, we want to add a French site which has its own content, there would be besides the host configuration we saw before for example an extra hst:site nodes, namely example-fr, and an extra content entry /content/documents/example-fr.
The hst:site node ( example) also points to a configuration with an hst:sitemap that contains information for a (sub)site how the remainer of the URL after the matched Mount is matched, and how subsequently a page is rendered (request processing). This configuration is configured at /hst:hst/hst:configurations/{myproject}. An hst:site can have an explicit property hst:configurationpath pointing to some hst:configuration, or, if it is missing, it takes the configuration by convention: The name of the hst:site is filled in for {project} for /hst:hst/hst:configurations/ {myproject} and that is the location where the hst:configuration is looked up from. Preferred is to  not explicitly configure the hst:configuration location but to keep it by convention.


The node at /hst:hst/hst:configurations/{myproject} is of type hst:configuration, and contains by default the structure below. The hst:sitemap contains the configuration for the last part of the request matching. The rest of the configuration like hst:components, hst:pages, hst:template, etc is for the request processing.

+ hst:hst
   + hst:configurations
   | + hst:default
   | + example               [hst:configuration]
   |   + hst:abstractpages
   |   + hst:catalog
   |   + hst:components
   |   + hst:pages
   |   + hst:prototypepages
   |   + hst:sitemap
   |   + hst:templates
   |   + hst:workspace
   + hst:sites
       + example              [hst:site]




Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?