Sling Framework Part – 2

Sling Post Servlet, Resource Resolver, Service Users

Welcome to the second part of the Sling Framework.

After completing this part, you should be able to

1. Describe the purpose of Sling Post Servlet and How it works.
2. Work with Sling Resource Resolver.
3. Understand the concept of service users.
4. Understand context-aware configurations.

Sling POST Servlet

Sling POST Servlet is one of the key features of Sling.
It handles all POST operations to Sling instance by default.
This servlet provides possibility to create, modify, copy-move, delete to invoke resources.
It can be extended with additional POST operations and PostProcessor.
The Servlet can be called with a standard form submission as you can see on this eg.

<form method="POST" action="/content/page" enctype="multipart/form-data">
    <input type="text" name="title" value="" />
    <input type="Submit" />
</form>

The action property is a node path in the repository, this node will be modified during Sling Servlet POST execution.
The name property in parameter contains, a node property which will be modified, and value property – defines a new value for the node’s property.

After this form submission “title”- property will be set on a node “/content/page”.

Sling POST Servlet is actively used in AEM, it allows you to create, update, delete nodes and properties, copy-move nodes etc.
When you create new Servlet, if you just need to update something in the repository you can use Sling POST Servlet to cover all those mentioned requirements.

Default Servlets

Here are main Servlets of Sling framework

• SlingMainServlet
  • Entry point into the Sling request handling after authentication.
    
• DefaultGetServlet
  • Provides default renderers for resources (HTML, TXT, JSON, XML)
    
• SlingPostServlet
  • Allows extensive content manipulation (create, delete, update) through its REST API
    
• DefaultErrorHandlerServlet
  • Default error handler servlet registered at the end of the global search path

Mappings for Resource Resolver

http://localhost:4502/system/console/jcrresolver

Resource Resolver defines order of how scripts are searching for libs, apps and other folders.
Also, it is used to determine rules for constructing URL. You can use Resource Resolver to specify additional rules for URL’s and paths, like making pages available at shorten URL instead of the long one.
It’s possible to get resource using a completely different path not matching a path to their repository node.
To understand the correspondence between paths and resources in the repository you can use them in console for resource resolver, where you can insert the address in a field and see the real address in a repository or shortened address for this node.

Resource Resolver – Inheritance

We already know about inheritance in Apache Sling using property sling:resourceSuperType, but AEM also provides one more way to override Out-of-the-box component which usually stores under libs folder.

For that you just can copy the script which you want to override under the apps folder with the same structure. This way of overriding core components behavior is called Overlay.

Resource Resolver

Resource Resolver is a gateway for resources, It abstracts the path resolution and access to the persistence layer.
Resource resolver has two main methods.

1. resolve(): which is central method for matching a path to a resource.
2. map(): inverse operation to resolve(), yielding an external path for a resource path.

You can get resource resolver from Sling Request
eg. SlingHttpServletRequest.getResourceResolver()

Also, you get JCR session by adapting it from resource resolver
eg. slingRequest.getResourceResolver().adaptTo(Session.class);

Service Users

SlingRepository.loginAdministrative() and ResourceResolverFactory.getAdministrativeResourceResolver() are now deprecated.

Sling offers a Service User Mapping Service which allows you to configure a bundle to user mapping and to corresponding API methods.

Sling repository login service and resource resolver factory, get service resource resolver which returns a session or resource resolver with a privilege of a configured user only.

Steps to configure and use service users:

1. Create a system user, set permissions.
2. Add configuration for org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl
3. Use SlingRepository.loginService() and ResourceResolverFactory.getServiceResourceResolver()

Click here to read detailed steps about Service User Mapper in AEM.

Sling Context – Aware Configuration

Context-aware configurations are configurations that are related to a content resource or a resource tree like a web site.
The application needs a different configuration for different sites, regions they are all different contexts. Some parameters may be shared, so inheritance for nested contexts and for those global fallback values is supported as well.
You have full control which contents of trees are the context in your application.
Using the context-aware configuration Java API, you can get matching configuration for each content resource without caring where it is stored or how the inheritance works.

Hope you enjoyed this article, I would like to suggest, Kindly watch below video for better understanding with practical session. Thank you for your attention!