Understanding Resource Types, Resource Super Types and Component Resolution in AEM

How Sling Finds the Component That Renders Your Content

We Found the Resource. Now What?

Imagine a request reaches Sling.

ResourceResolver successfully locates

/content/company/us/en/home/jcr:content/root/title

Sling now has a Resource.

However, another important question still remains.

Which component should render this content?

The Resource contains content.

But content alone is not enough.

Sling still needs to determine

Which HTL file?
Which Sling Model?
Which script?
Which component?

The answer comes from one property

sling:resourceType

This property drives almost every rendering decision in AEM.

Component Resolution Starts Here

What Is sling:resourceType?

Real example.

Repository:

/content/company/us/en/home/jcr:content/root/title

Properties:

jcr:title = Welcome
sling:resourceType = company/components/title

At this point, Sling has two different pieces of information.

The first is the content itself.

jcr:title = Welcome

The second is the instruction that tells Sling how that content should be rendered.

sling:resourceType = company/components/title

Think of it this way.

The content contains the data.

The resourceType contains the rendering logic.

Without a resourceType, Sling would know what content exists, but it would not know which component should render that content.

This property tells Sling

Do not render me directly.

Use the component located at

/apps/company/components/title

Architect Analogy

Resource = Data

resourceType = Renderer

Or:

Book = Content

resourceType = Reader

The content doesn’t know how to display itself.

The component does.

Resource Type Mapping

Content Resource /content/company/us/en/home/jcr:content/root/title │ ▼ sling:resourceType company/components/title │ ▼ Component Path /apps/company/components/title │ ▼ title.html │ ▼ HTML Output

Resource Contains Content

sling:resourceType Points To Component

Component Contains Rendering Logic

HTL Generates HTML

How Sling Finds the HTL File

This is where people start understanding component resolution.

Suppose

sling:resourceType =
company/components/title

Sling searches

/apps/company/components/title/title.html

When Sling reads:

sling:resourceType=company/components/title

it converts that value into a component path.

company/components/title

becomes

/apps/company/components/title

Sling then searches that component folder for scripts that can handle the current request.

For a standard page request, Sling typically looks for

title.html

If the script is found, rendering continues.

If no matching script can be located, the component cannot render.

Real Production Scenario

Component exists in content.

• Page loads.
• Component missing.

Why?

Because:

resourceType points here

company/components/title

but:

/apps/company/components/title

does not exist.

This happens frequently after deployments.

Sling Found the Component. What Happens Next?

Imagine Sling resolves

company/components/title

and locates

/apps/company/components/title

However, the component folder may contain

title.html
title.json
GET.java
POST.java

Which one should Sling execute?

This is where Script Resolution begins.

At this point, many developers assume Component Resolution and Script Resolution are the same thing.

They are actually two different stages in the Sling rendering process.

Component Resolution identifies which component should handle the content.

Script Resolution identifies which script inside that component should handle the request.

Understanding the difference makes it much easier to troubleshoot rendering issues and servlet execution problems.

Component Resolution vs Script Resolution

What Is Script Resolution?

Sling uses several factors:

Resource Type
+
HTTP Method
+
Selectors
+
Extension

to determine which script should handle the request.

Think of Script Resolution as a matching process.

Component Resolution already identified the component that should render the content.

Now Sling must decide which script inside that component should handle the request.

A component may contain

title.html title.model.json TitleServlet.java

All of these belong to the same component, but they serve different request types.

Script Resolution is responsible for selecting the best match based on the incoming request.

Example 1

Request:

/content/site/en/home.html

Sling sees:

Method     = GET
Extension  = html

Result:

title.html

gets executed.

Example 2

Request:

/content/site/en/home.model.json

Sling sees:

Selector = model
Extension = json

Result:

JSON Exporter

gets executed.

This is exactly what AEM SPA Editor and Headless AEM use.

Example 3

Request:

/content/site/en/home.delete.html

Sling sees:

Selector = delete
Method = POST

Result:

Delete Servlet

may be executed.

Architect Visualization

How Sling Chooses a Script

Request
      ↓
Resource
      ↓
resourceType
      ↓
Method
      ↓
Selectors
      ↓
Extension
      ↓
Best Matching Script

Real Production Example

Why Is My Servlet Not Being Called?

A common production issue

Developer creates:

@SlingServletResourceTypes(
resourceTypes="company/components/page",
selectors="export",
extensions="json"
)

Request:

/home.json

Servlet never executes.

Why?

Because:

Expected:
home.export.json

Actual:
home.json

Selector mismatch.

Many developers spend hours debugging code when the issue is actually script resolution.

Script Resolution Troubleshooting Checklist

[embed]

What Is sling:resourceSuperType?

This is where Core Components enter.

Imagine

company/components/customtitle

Instead of creating everything from scratch

sling:resourceSuperType =
core/wcm/components/title/v3/title

Now Sling says

Use custom component first.

If something is missing,
inherit from Core Component

This inheritance model is one of the reasons Core Components became so successful.

Imagine Adobe releases a new enhancement for the Core Title Component.

If your project copied the entire component, you would need to manually compare, merge, test, and maintain those changes.

However, when using sling:resourceSuperType, your component continues inheriting improvements from the Core Component while still allowing project-specific customizations.

This significantly reduces maintenance effort and helps projects stay aligned with future Adobe updates.

Resource Super Type Inheritance

Why Proxy Components Exist

This section is mandatory.

Many blogs skip it.

Bad approach:

Copy Core Component
Modify Code

Problem

Adobe releases update
↓
Your copy never gets it

Good approach

Proxy Component
↓
resourceSuperType
↓
Core Component

Benefits:

Inheritance
Upgrades
Less Maintenance
Cleaner Code

Real Production Example

Many enterprise projects contain

/apps/company/components/title

but almost no HTL.

Why?

Because:

resourceSuperType

does most of the work.

This surprises many developers the first time they see it.

Copy vs Inheritance

Real Production Scenario: Component Not Rendering

[embed]

Component Resolution Troubleshooting

Putting Everything Together

At this point we can finally understand the complete rendering journey.

1. ResourceResolver finds the Resource.
2. Sling reads sling:resourceType.
3. Component Resolution locates the component.
4. Script Resolution selects the appropriate script.
5. Sling Models provide business data.
6. HTL generates HTML.
7. The response is returned to the browser.

What initially appears to be a simple page request is actually a series of resolution steps working together.

Understanding this chain makes it significantly easier to troubleshoot rendering problems because you can identify exactly where the process breaks down.

Complete Sling Rendering Flow

Why Architects Care About Resource Types

This is where we differentiate the article.

Most developers think

resourceType = property

Architects think

resourceType = rendering engine

Without it

No HTL
No Sling Model
No Component
No Rendering

Understanding resource types is often the moment when developers truly understand how Sling rendering works.

Architects rarely troubleshoot rendering problems by starting with HTL.

Instead, they follow the rendering chain.

Resource ↓ resourceType ↓ Component Resolution ↓ Script Resolution ↓ Sling Model ↓ HTL ↓ Response

The earlier a failure occurs in this chain, the less useful it becomes to investigate rendering code.

In the next blog, we will move beyond the request itself and explore Selectors, Extensions, Suffixes and Request Path Decomposition in AEM.

Every great discussion starts with a simple thought! If you enjoyed this article, found it useful, or have any questions, let’s talk! I’d love to hear from you.

For more updates, tips, and engaging conversations, connect with me on **Medium, and LinkedIn, **Let’s keep learning together! 🚀✨

Thank you 🙏 !