In a basic setup with just one Sling instance or a homogenous Sling cluster, the most performant way to present the public release is to configure a virtual host accessing the Sling instance / Sling cluster, and set the publish policy to InPlace replication on the Site. This copies the public release of the site into a path configured in the Composum Pages Replication Configuration (by default /public). This replication is repeated on each change of the release marked as public / on each move of the public mark.

Besides setting up the virtual host (e.g. with a load balancer or apache, preferably caching requests), an appropriate mapping into the resource tree below /public needs to be configured (see URL Mappings for Resource Resolution). (It might be necessary to change the settings in the "Apache Sling Resource Resolver Factory".)

Caution: in an installation of Platform and Pages without the Tenants enterprise module, it will be neccesary to allow readability to the replicated release in /public and /libs/composum/pages/components for everyone.

If no release management is wanted, it is possible to set a site to "Live immediately". Thus, all changes made to pages are immediately shown to the public. This setting requires a virtual host that is not configured as an author host, defining an appropriate URL mapping and making the required parts of /content readable for everyone.

When set to publish policy "Versions resolver", the site content is served directly from the checked in versions of the pages according the release marked as "public" via the StagingResolver described in Staging. This requires configuring the URL mapping for the (non author) virtual host according to the normal content path of the site.

Please keep in mind that this setting reduces the performance of the site, since the release JCR content is reconstructed from version storage on the fly.

This also requires opening the permissions of the site to everyone.

To make it easier to follow the log entries one request generates through the various logfiles, some suggestions for configuring the logging.

• For both the access log and the request log it is possible to log the thread name by setting the mesage pattern for the corresponding configuration to %msg [%t]%n . But please note that  the thead name is temporarily changed to something that describes the request, so it'll be different in error.log. Thus this just makes some crossreferences easier.
• You can add another request data logger with a custom pattern to the "Apache Sling Customizable Request Data Logger". For example, to get another entry per request in the request.log you can use the logger name "log.request", type of  destination to "Logger Name", and a log format %t [%R] = %v %{X-Forwarded-For}i %{JSESSIONID}C %{Referer}i will write an additional line with the canonical hostname the request was received at (important in the case of several virtual hosts), the IP it comes from (if you got an apache as front end), the session id and the Referer header. (Please be aware that the session id is a security risk if an attacker is able to read this logfile. It would be better to somehow find another unique id to follow the requests of one session.)