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.

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 {
    @Override
    public void doBeforeRender(final HstRequest request,
                               final HstResponse response)
                                      throws HstComponentException {
        final Mount mount =
           request.getRequestContext().getResolvedMount().getMount();
        // WebsiteInfo is an interface that extends from
        //   o.h.h.configuration.channel.ChannelInfo
        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]