Sling Resource Resolver Simulator — User Guide

Simulates how AEM's Sling resource resolver would map a request path, based on rules you define. This is a simplified, educational approximation — it doesn't talk to a real AEM instance and doesn't implement the full MapEntries algorithm (scheme/host matching, vanity paths, JCR-order precedence).

Prefix rules (the common case)

Most real-world /etc/map setups boil down to prefix rewrites — e.g. /content/mysite/en externally serves as /en.

1. Add rules as internal repository path ⇄ external URL path pairs.
2. Pick a direction:
   • Resolve — simulates an incoming request: external URL path → internal repository path.
   • Map — simulates building a link: internal repository path → external URL path.
3. Enter the path you want to test. The tool applies longest-prefix-wins — if you have both /en and /en/products rules, a request under /en/products/... uses the more specific rule.
4. The trace shows every rule considered and why it did or didn't match.

Regex rules (advanced)

For rewrites that aren't simple prefix substitutions (e.g. extracting an ID from the path), switch to Regex rules. Rules apply in the order listed, first match wins. The replacement can use capture groups ($1, $2, …).

What this doesn't simulate

• Scheme/host-specific mapping (https://www.example.com/...).
• Vanity URLs stored on individual pages.
• The real ordering AEM uses when multiple /etc/map nodes could apply (this tool uses your listed order / longest-prefix instead).

Use this to sanity-check a proposed mapping table before writing it into /etc/map, not as a substitute for testing on a real AEM instance.