Extending AEM Components Using sling:resourceSuperType — Powered by Sling Resource Merger

Quote's of the day
"You never fail until you stop trying"

What is Sling Resource Merger?

•  Sling Resource Merger is the hidden engine that makes AEM’s inheritance powerful.
• It allows developers to extend, reuse, and customize components efficiently — without touching the original ones.

⚙️ Where It Is Used in AEM

     Sling Resorce Merger works :

             When extending a component

                 a). What it is: Create a new component that inherits from an existing one.

               b). How it works:Use sling:resourceSuperType to point to the parent component.

               c). Key point: Only the parts you override (dialog, HTML) are changed; the rest                                 comes from the parent via Sling Resource Merger.

🧩 Purpose:

•  We have an existing component in our AEM project (not core, our own).
•  We found that our new component will use 80% of the same fields.
•  So, instead of copying everything, we decide to extend and customize it.

Note: Here, PersonalInfo is my existing component, and the existing fields are FirstName and SecondName.

Sling Model interface for the existing component.

Sling Model implementation class for the existing component.

This  is HTL file

Data is rendered for the existing component on the page.

Step 1:  Create a (PersonalInfoExtend) new Component & extend the existing component with                                       sling:resourceSuperType Property.

Step 2: Create a Sling Model interface for the PersonalInfoExtend component.

In this example, we have created an interface called PersonalInfoExtend inside the package

com.adobe.aem.guides.wknd.core.models.

Explanation

• The PersonalInfoExtend interface extends another interface called PersonalInfo.
• This means it inherits all methods from PersonalInfo.

• Along with the inherited methods, it also adds two new methods:

  • getAge() → to fetch or return the user’s age.

  • getSalary() → to fetch or return the user’s salary.

  This approach helps in reusing existing functionality (from PersonalInfo) and extending it with new fields without changing the original code.

Step 3: Create a Sling Model implement class for the PersonalInfoExtend component.

In this example, we’ve created a class called PersonalInfoExtendImpl inside the package

com.adobe.aem.guides.wknd.core.models.







Explanation 

• This class implements the interface PersonalInfoExtend — meaning it provides the actual logic (or data) for the methods defined in that interface.
• It also extends another class, PersonalInfoImpl, so it inherits all the existing properties and methods from it.

                  → This helps in reusing existing code instead of writing everything again.

Step 4: Create an HTL file for the PersonalInfoExtend component.

 

This is an authoring field on the page.

The extended component fetches and renders data on the page.

Thanks for Watching !!

Mastering URL Shortening in AEM: Vanity URLs and Beyond

Quote of the Day

" Train your mind to see the good in every situation  "

 What is URL shortening (or shorthand URL)?

A URL shortening (or shorthand URL) is a way to make a long, complicated web address shorter and easier to share. 

Instead of sharing a long URL like:

https://www.colibra.com/content/weretail/us/en/products/womens/shoes.html

We can create a short, friendly URL like:

https://www.colibra.com/shoes

We have three ways to do URL shortening/create shorthand URLs.

1.Vanity URL

2.Redirect/Rewrite Rule

3.etc Mapping

Here, we discussed how to implement URL shortening in AEM using Vanity URLs and how AEM handles this internally.

How we can add AEM vanity Url for a particular page

Step 1: Navigate to this URL and download vanity URL’s components package.

Step 2: Accept EULA terms and conditions and press download button highlighted red in color.

Step 3: Upload vanityurls-components package and install on publish instance:

 Step 4: To add a vanity URL for a specific field available in the page properties.

Go to the page and open its properties.

 

Step 5: Here, the Vanity URL property is a multi-field, which means you can apply multiple vanity URLs for this page.

Step 6: These vanity URLs are mapped as Sling mappings.

    

step 7: after that Save&Close.

Note:

• The Vanity URL is based on the page, not the domain.
• Vanity URLs work on both Author and Publish instances.

Step 8: Now access this page.

Step 9: If we want to publish this page, we must first replicate it.

Step 10: Page is accesible using Vanity Url on Publish.

⚙️ How It Works Internally

1.Vanity Property in JCR Node

• In the JCR repository, when a content author sets a Vanity URL for a page, AEM stores it as a property inside the page’s jcr:content node:
• For example,
  /content/wknd/us/en/author-info/jcr:content.
• sling:vanityPath = "/author-info"

---

1. AEM provides an internal resource at:

• /libs/granite/dispatcher/content/vanityUrls
• This path is part of AEM’s Granite UI framework and is responsible for exposing vanity URL mappings.

  2. sling:resourceType Mapping

• Node, sling:resourceType = granite/dispatcher/components/vanityUrls

• This means that when the resource is requested, AEM uses the component located at: /libs/granite/dispatcher/components/vanityUrl to render the response.

 

 3. Accessing in Browser

• When you open this path in a browser (e.g., http://localhost:4502/libs/granite/dispatcher/content/vanityUrls.html), AEM dynamically generates response.
• This response contains all the registered vanity URL mappings across the repository (collected from sling:vanityPath properties).

🔎 How AEM Compares and Traverses Vanity URLs Internally

1. Saving the Vanity URL

• In the page node (/content/wknd/us/en/author-info/jcr:content), AEM adds a property:

sling:vanityPath = "/author-info"

At this point, if we check the /vanityUrls.html response, we’ll see our vanity mapping, which confirms it’s saved.

• When  hit http://localhost:4502/author-info

sling checks its vanity path mappings.

If a match is found → it traverses the mapping and internally redirects to the actual page path (/content/wknd/us/en/author-info).

On the Dispatcher / Web Server, sometimes the page cannot be accessed using the configured Vanity URL.

Let’s see how we can resolve such issues:

Step 11: To allow Vanity URLs on Dispatcher

We need to add the /vanity_urls section inside the dispatcher.any file. This section allows the dispatcher to resolve Vanity URLs. Here, we have to define three properties:

• /url → This property points to the service that returns all the available Vanity URLs configured in AEM.
• /file → Dispatcher stores these Vanity URL mappings in the specified file. This allows the dispatcher to frequently check and resolve Vanity URLs without calling AEM every time.
• /delay → This defines the time interval (in seconds) between consecutive calls that the dispatcher makes to AEM to refresh the Vanity URL list.

 Advantages of Vanity URLs

• Easy to remember – Short and clean links are more user-friendly.

• Author controlled – Content authors can manage URLs directly from page properties.

• Marketing friendly – Perfect for campaigns, landing pages, and promotional content.

Disadvantages of Vanity URLs

• Performance impact – Vanity URLs are resolved at runtime. If you configure thousands of vanity URLs or sling mappings, it can become an expensive operation in terms of resources.

• Dispatcher setup required – Vanity URLs must be enabled and properly configured in the dispatcher.

• Not scalable for bulk usage – If many URLs need to be shortened, other approaches like Apache rewrite rules or URL mapping may perform better.

     Thanks !!

How to Configure Dispatcher Flush Agent in AEM: A Practical Guide

🌟 Quote of the Day

"Sometimes you win, sometimes you learn."

Dispatcher Flush Agent

It is replication agent used to clear/invalidate cache from the Dispatcher whenever content is activated or deactivated.

Multiple Ways to Clear Cache on Dispatcher

1. Using AEM Dispatcher Flush Agent – Automatically clears cache when content is activated or deactivated.

2. Using ACS Commons – Provides additional tools and utilities to invalidate or flush dispatcher cache selectively.

3. Manual or Custom Code – Manually deleting cached files on the dispatcher or writing scripts to programmatically clear cache.

 

How to Configure Dispatcher Flush Agent

1. Dispatcher Flush Agent on Author

• Not recommended in most cases.

• Author instance is primarily for content creation, not for serving live traffic.

• If configured, it can trigger cache invalidation on the dispatcher, but it may cause unnecessary load.

2. Dispatcher Flush Agent on Publish

• Recommended approach.

• Publish instance serves live content through the dispatcher.

• Flush agent is triggered automatically whenever content is activated (published) or deactivated, clearing the relevant cache.

Steps to configure:

1. Traverse to author instance. http://localhost:4502/sites.html/content

 2. Click on Adobe Experience Manager icon → tools → Deployment → Replication as shown below:

3. Click on Agents on Author as highlighted below:

4. Select Dispatcher flush option as shown below:

5. Click on Edit option as highlighted below:

6. Set dispatcher URL and PORT as shown below:

http://localhost:80/dispatcher/invalidate.cache

7. Check the Enabled checkbox to enable disable flush agent. Click on OK to save the changes.

8. It will show below highlighted green color radio button on successful enable.

9. Click on Test Connection anchor link to verify connection in between dispatcher and author instance.

10. To resolve above issue, lets open dispatcher.any file and update below line to allow 127.0.0.1 address:

Inside allowedClients we can allow specific IP addresses or IP ranges which are permitted to access the Dispatcher or AEM instance.

11. Below is the screen shot of the page and its cached timestamp.

12. Publish the home page as shown below:

13. home page will get deleted from the cache directory, as shown below, as soon as we publish the page.

Dispatcher Flush Agent on Publish

Steps to configure:

1. Click on Adobe Experience Manager icon → tools → Deployment → Replication as shown below:

3. Click on Agents on publish as highlighted below:

4. Select Dispatcher flush option as shown below:

5. Click on Edit option as highlighted below:

6. Set dispatcher URL and PORT as shown below:

7. Check the Enabled checkbox to enable disable flush agent. Click on OK to save the changes.

The Author and Publish instances share the same base AEM setup, but their configurations differ based on their role: 

Author = content creation, Publish = content delivery.

🔹 Step-by-Step Flow After Publish/Activate

1. Author Instance (Content Created/Updated)

• Author creates or edits a page, asset, or component.

• When finished, the content is published (activated).

---

2. Replication Agent on Author

• The replication agent sends the content from Author → Publish.

• This includes the page/asset data, references, and metadata.

---

3. Publish Instance (Receives Content)

• The content is stored in the Publish instance JCR.

• Now, the publish instance has the latest version of that page/asset.

---

4. Dispatcher Flush Agent (on Publish)

• A dispatcher flush agent is triggered automatically.

• It tells the Dispatcher (cache layer) to clear or invalidate the old cache for that content.

---

5. Dispatcher (Cache Layer)

• Dispatcher removes the outdated cached file(s).

• The next time a visitor requests that page, Dispatcher fetches the fresh content from Publish and caches it again.

---

6. End User (Website Visitor)

• Visitor requests the page (e.g., homepage).

• Dispatcher serves the latest version that was just published.

• ✅ Website shows updated content instantly.

home page will get deleted from the cache directory, as shown below, as soon as we publish the page.

Thank you !!