Flexible Resource Resolution

Status: DRAFTIMPLEMENTED
Created: 25. November 2008
Author: fmeschbe
JIRA: SLING-249
References: http://markmail.org/message/cibaddpdfk2jwm7p^{Image Removed}, Mappings for Resource Resolution
Update: 28. November 2008, fmeschbe, Addition to node types and add section on backwards compatibility

...

Note, that these node types only help setting the properties. The implementation itself only cares for the properties and their values and not for any of these node types.

Root Level Mappings

Root Level Mappings apply to the request at large including the scheme, host.port and uri path. To accomplish this a path is constructed from the request as {scheme}/{host.port}/{uri_path}. This string is then matched against mapping entries below /etc/map which are structured in the content analogously. The longest matching entry string is used and the replacement, that is the redirection property, is applied.

Mapping Entry Specification

Each entry in the mapping table is a regular expression, which is constructed from the resource path below /etc/map. If any resource along the path has a sling:match property, the respective value is used in the corresponding segment instead of the resource name. Only resources either having a sling:redirect or sling:internalRedirect property are used as table entries. Other resources in the tree are just used to build the mapping structure.

Example

Consider the following content

Namespace Mangling

There are systems accessing Sling, which have a hard time handling URLs containing colons – : – in the path part correctly. Since URLs produced and supported by Sling may colons because JCR Item based resources may be namespaced (e.g. jcr:content), a special namespace mangling feature is built into the ResourceResolver.resolve and ResourceResolver(map) methods.

Namespace mangling operates such, that any namespace prefix identified in resource path to be mapped as an URL in the map methods is modfied such that the prefix is enclosed in underscores and the colon removed.

Example: The path /content/_a_sample/jcr:content/jcr:data.png is modified by namespace mangling in the map method to get at /content/_a_sample/_jcr_content/_jcr_data.png.

Conversely the resolve methods must undo such namespace mangling to get back at the resource path. This is simple done by modifying any path such that segments starting with an underscore enclosed prefix are changed by removing the underscores and adding a colon after the prefix. There is one catch, tough: Due to the way the SlingPostServlets automatically generates names, there may be cases where the actual name would be matching this mechanism. Therefore only prefixes are modified which are actually namespace prefixes.

Example: The path /content/_a_sample/jcr_content/_jcr_data.png is modified by namespace mangling in the resolve method to get /content/_a_sample/jcr:content/jcr:data.png. The prefix _a is not modified because there is no registered namespace with prefix a. On the other hand the prefix jcr is modified because there is of course a registered namespace with prefix jcr.

Root Level Mappings

Root Level Mappings apply to the request at large including the scheme, host.port and uri path. To accomplish this a path is constructed from the request as {scheme}/{host.port}/{uri_path}. This string is then matched against mapping entries below /etc/map which are structured in the content analogously. The longest matching entry string is used and the replacement, that is the redirection property, is applied.

Mapping Entry Specification

Each entry in the mapping table is a regular expression, which is constructed from the resource path below /etc/map. If any resource along the path has a sling:match property, the respective value is used in the corresponding segment instead of the resource name. Only resources either having a sling:redirect or sling:internalRedirect property are used as table entries. Other resources in the tree are just used to build the mapping structure.

Example

Consider the following content

/etc/map
      

/etc/map
      +-- http
           +-- example.com.80
                +-- sling:redirect = "http://www.example.com/"
           +-- www.example.com.80
                +-- sling:internalRedirect = "/example"
           +-- any_example.com.80
                +-- sling:match = ".+\.example\.com\.80"
                +-- sling:redirect = "http://www.example.com/"
           +-- localhost_any
                +-- sling:match = "localhost\.\d*"
                +-- sling:internalRedirect = "/content"
                +-- cgi-bin
                     +-- sling:internalRedirect = "/scripts"
                +-- gateway
                     +-- sling:internalRedirect = "http://gbiv.com" 
                +-- (stories)
                     +-- sling:internalRedirect = "/anecdotes/$1" 

...

Regular Expression	Redirect	Internal	Description
http/example.com.80	http://www.example.comImage Removed	no	Redirect all requests to the Second Level Domain to www
http/www.example.com.80	/example	yes	Prefix the URI paths of the requests sent to this domain with the string /example
http/.+\.example\.com\.80	http://www.example.comImage Removed	no	Redirect all requests to sub domains to www. The actual regular expression for the host.port segment is taken from the sling:match property.
http/localhost\.\d*	/content	yes	Prefix the URI paths with /content for requests to localhost, regardless of actual port the request was received on. This entry only applies if the URI path does not start with /cgi-bin, gateway or stories because there are longer match entries. The actual regular expression for the host.port segment is taken from the sling:match property.
http/localhost\.\d*/cgi-bin	/scripts	yes	Replace the /cgi-bin prefix in the URI path with /scripts for requests to localhost, regardless of actual port the request was received on.
http/localhost\.\d*/gateway	http://gbiv.comImage Removed	yes	Replace the /gateway prefix in the URI path with {{ http://gbiv.comImage Removed }} for requests to localhost, regardless of actual port the request was received on.
http/localhost\.\d*/(stories)	/anecdotes/stories	yes	Prepend the URI paths starting with /stories with /anecdotes for requests to localhost, regardless of actual port the request was received on.

...

In Revision 720647 of Sling trunk I have implemented a first shot at a new JCR resource resolver. This resource resolver currently lives side-by-side with the old one and the JcrResourceResolverFactoryImpl decides based on configuration (Configuration Admin configuration or framework property of the name resource.resolver.new) whether the new or the old resource resolver is to be used. The default is to use the new resource resolver.

The new resource resolver currently has the following setup:

resource resolver currently lives side-by-side with the old one and the JcrResourceResolverFactoryImpl decides based on configuration (Configuration Admin configuration or framework property of the name resource.resolver.new) whether the new or the old resource resolver is to be used. The default is to use the new resource resolver.

The new resource resolver currently has the following setup:

• /etc/map – Mappings are read from /etc/map as described above
• Vanity URLs – Existing vanity URL configuration is added as map entries, where the regular expression{{./.}} as the prefix to indicate scheme and host.port are ignored.
• URL Mappings – Existing URL mapping configuration added as map entries where multiple internal path mappings for the same external path are collected into a single entry with multiple internal redirects. Again the scheme and host.port are ignored that is the entries are prefixed with ./..
• Regular Expressions – Regular expression mappings are not supported like this anymore. These must be migrated manually to respective entries in /etc/map. The main reason to have regular expression mapping was support for namespace mangling (see above), which has been implemented differently (see below).
• VanityPath –
• All configuration except the search path is ignored.
• Mappings are read from /etc/map as described above. There are no default settings for now.
• Existing sling:vanityPath settings are loaded as map entries where the sling:vanityPath property defines the regular expression (using the fixed string ./. to indicate that the entry applies for any scheme and any host.port. The path of the node having the sling:vanityPath property is used as the redirect path. Finally the sling:redirect property of the node is used to decided whether the redirect is internal (property is false or missing) or external (property is set to true).
• Namespace Mangling – Namespace mangling as described in the Namespace Mangling section above is implemented.