Unit Testing JCR Resource Resolver Mappings | AEM Community Blog Seeding

[kautuk_sahni]

Unit Testing JCR Resource Resolver Mappings by Perficient

Abstract

Recently, I had a task to shorten URLs and remove the HTML extension in AEM. On top of that, I had to add a context root to the URLs so that these mappings would happen.
1. /content/myapp/en_US.html -> /mycontext/
2. /content/myapp/en_US/homepage.html -> /mycontext/homepage/
3. /content/myapp/es_ES.html -> /mycontext/es_ES/
4. /content/myapp/es_ES/homepage.html -> /mycontext/es_ES/homepage/

Shorting URLs in AEM consists of two things:
1. The dispatcher will receive requests for short extension-less URLs and must rewrite them before passing them through to the publishers.
2. The links within the HTML markup rendered by AEM must be rewritten to their short extension-less versions.

Setting up Apache is straight forward. You need to inspect the incoming request and translate it to its long version before sending it on to AEM. What I had trouble with was configuring the Sling mappings to rewrite URLs. There are 2 ways to achieve this:
1. Update the content under /etc/map
2. Add the mapping to the resource.resolver.mapping property of the org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl OSGi configuration

What I Do
In general, I have always opted for the second. I find it is simpler to manage than managing content under /etc/map. The only annoying thing is that if you make a change it causes every OSGi component that depends on it to restart. Having to wait a long time between changes is frustrating. This is especially true if I am trying to work out new mapping rules.

Nowadays, I find myself doing more and more TDD. In particular, I’ve been leveraging wcm.io Sling Mocks. With JUnit 5 and AssertJ, I can develop Sling Models and OSGi components without ever having to load a page.

Read Full Blog

Unit Testing JCR Resource Resolver Mappings

Q&A

Please use this thread to ask the related questions.