Sling URIs and the new URI Mapping SPI

Resource Mapping has been around in Sling from the first days. We all have worked with either simple JcrResourceResolverFactoryImpl configs and/or more complicated /etc/map-Setups. To make it more interesting we have fought our way through Apache rewrite rules, farm configurations and correct de-caching, http vs. https issues (luckily today it's almost always https only!) and tenant-unique vanity paths (when Sling only knows them per server instance). We have adjusted links using String operations and we have gotten it sometimes wrong (because there is always this one special link incarnation we didn't think of during implementation).

Now all that will not completely go away with the new Sling URI Mapping SPI, but yet our life will become easier by:

• Introducing the interface SlingUri and SlingUriBuilder help simplifying code around link handling
• Extending the mapping process via a well-defined API that allows to write Turing-complete code is often more flexible and than the current purely declarative approaches (config for JcrResourceResolverFactoryImpl or /etc/map) - a flexibility that is otherwise only possible Rewriting Pipelines
• Automatically mapping links (display context "uri") in HTL. With this new approach many setups can do without the Rewriting Pipelines (that come itself some limitations) which is a great opportunity to improve performance. Also debugging gets easier since the mapping happens directly and is not decoupled via the response output stream.

The talk will show some examples on how to extend the resource mapping and give a quick demo on it.