Hosts Configuration

This part of the configuration contains the information for host and mount (sub site/channel) matching. Since we store the host information for all the available sites in the repository, the HST supports multiple hosts within a single application, and since the host information for all the available sites is stored in the repository, webmasters can add new hosts in a running production environment. This is done through the channel manager making use of blueprints.

To support a single host configuration quarantined between local development, test, acceptance and production environments, the first nodes below the hst:hosts node are the hostgroup nodes which are of type hst:virtualhostgroup. The goal of a virtualhostgroup is group hosts that can cross link to each other, but not across hostgroups: The HST will never create a link between for example test and production environment this way. After the hostgroup nodes, the host nodes follow, and finally the mount nodes. Hosts are hierarchically configured in reversed order, unless they are an ip-address. An example hst:hosts configuration without mounts looks like:

/hst:hosts:
  jcr:primaryType: hst:virtualhosts
  /dev-env:
    jcr:primaryType: hst:virtualhostgroup
    /localhost:
      jcr:primaryType: hst:virtualhost
  /test-ip-env:
    jcr:primaryType: hst:virtualhostgroup
    /81.21.138.121:
      jcr:primaryType: hst:virtualhost
  /test-env:
    jcr:primaryType: hst:virtualhostgroup
    /com:
      jcr:primaryType: hst:virtualhost
      /example:
        jcr:primaryType: hst:virtualhost
        /test:
          jcr:primaryType: hst:virtualhost
      /example2:
        jcr:primaryType: hst:virtualhost
        /test:
          jcr:primaryType: hst:virtualhost
  /acct-env:
    jcr:primaryType: hst:virtualhostgroup
    /com:
      jcr:primaryType: hst:virtualhost
      /example:
        jcr:primaryType: hst:virtualhost
        /acct:
          jcr:primaryType: hst:virtualhost
      /example2:
        jcr:primaryType: hst:virtualhost
        /acct:
          jcr:primaryType: hst:virtualhost
  /prod-env:
    jcr:primaryType: hst:virtualhostgroup
    /com:
      jcr:primaryType: hst:virtualhost
      /example:
        jcr:primaryType: hst:virtualhost
        /www:
          jcr:primaryType: hst:virtualhost
      /example2:
        jcr:primaryType: hst:virtualhost
        /www:
          jcr:primaryType: hst:virtualhost

After a host node, to make the host really available for the HST matching, an hst:mount node needs to be configured with the name hst:root. The hst:root mount is interpreted as ‘ /’. Below an  hst:root mount node, descendant mounts can be configured: These are sub-sites below a host. Adding mounts to the host configuration example above (and ignore test-env, test-ip-env and acct-env for simplicity) results in for example:

/hst:hosts:
  jcr:primaryType: hst:virtualhosts
  /dev-env:
    jcr:primaryType: hst:virtualhostgroup
    /localhost:
      jcr:primaryType: hst:virtualhost
      /hst:root:
        jcr:primaryType: hst:mount
        /test2:
          jcr:primaryType: hst:mount
  /prod-env:
    jcr:primaryType: hst:virtualhostgroup
    /com:
      jcr:primaryType: hst:virtualhost
      /example:
        jcr:primaryType: hst:virtualhost
        /www:
          jcr:primaryType: hst:virtualhost
          /hst:root:
            jcr:primaryType: hst:mount
      /example2:
        jcr:primaryType: hst:virtualhost
        /www:
          jcr:primaryType: hst:virtualhost
          /hst:root:
            jcr:primaryType: hst:mount

Now, the following hosts and sub-channels are available (ignoring ports):
dev-env:

1. http://localhost/
2. http://localhost/test2

prod-env:

1. http://www.example.com/
2. http://www.example2.com/

When a request hits the HST application, the request is first matched against the host and mount configuration. See HostName Matching and Mount Matching for an explanation of how the matching rules work. In a nutshell, a request is matched to the best possible matching host and mount. Since on a hst:mount node a developer must configure the following property:

hst:mountpoint : path to hst:site node for the request

*The hst:mountpoint can in exceptional setups also point directly to a content location below /content/documents. Then that mount is not mapped via an hst:sitemap and does not have HMVC rendering. This might be useful for example for REST endpoints that do not need a mapping. Or for example for PDF generation of repository content.

The HST application now knows for the request which hst:site and which hst:channel to use to proceed the request handling with. See Sites & Channels configuration for a further explanation.