Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Servlet / Script defined by path vs defined by resource

Avatar

Level 3

Hi All ,

   Warm greetings . I would like to know any use case or any example where servlet defined by resource is a better approach then defined by path (as mentioned in some of the blogs) .  I had a use case where a custom search component was developed which would retrieve locations list from JCR repo for a give post code .

So the approach we followed are ,

 Defined a custom servlet and registered it using path ( @slingservlet ( path = "mycustomservlet") . From 

 The custom servlet would execute custom search services which are registered in OSGI bundle along with the custom servlet .

 In the servlet after the service , the result is forwarded to a jsp which would render the result in list as json output . 

 

I include this component in one of page components and works fine  . In some blogs , it is mentioned that resolving the servlet via path is the best approach but couldn't figure out any advantages of using this one over the one we followed . 

Appreciate if any one can give some explanation with an example or  taking the above  usecase ?

regards

1 Accepted Solution

Avatar

Correct answer by
Level 2

Hi,

Registering a servlet by resource type is "the Sling way" of doing things, and therefore considered to be the preferred implementation in this context.  Basically it is just an alternative for implementing resource rendering code.  It can be used in the same way as you would use JSP scripts for rendering resources.  You can consider Servlets as a good (or "cleaner") implementation choice when your processing logic outweighs actual rendering logic.

For example, imagine a component that is responsible for creating a sitemap.xml using some form of sophisticated business logic for a global, multi-language site.  The component (and therefore the defined resource) can be placed at different levels of your site.  The component would provide a dialog for various configuration options.  You can then register a Servlet as the default rendering mechanism for your sitemap resource type, so it can read the configuration, process data, and write the XML rendition to the client.

Hope this helps,
Gregor

View solution in original post

6 Replies

Avatar

Level 8

One benefit to using resource-based servlets is that access restriction is sort of built into the solution already. The user request needs access to the resource before the call to the servlet is made. With path-based servlets you need to secure the path as well as the resource.

 

scott

Avatar

Level 3

Hi Gregor ,

  Thanks for your reply , this  gives a clarity on when to use a jsp script or a servlet for rendering your custom component and  helps .But my question was more focussed on the advantages of defining a servlet or a script by resource type rather than a path . With servlet defined by path I get my functionality done , but in some posts it is mentioned that preferred way is to get your scripts/ servlets resolved by resource type . So wanted to get more clarity on the advantages ? Would there be any extra decoupling or dynamism ... ?

 

Servlet Defined By Path:

@SlingServlet(

description = "My  Servlet",
generateService = true,
generateComponent = true,
label = "This is the only Servlet you will ever need...",
metatype = true,
methods = { "GET" },

name = "com.example.cq5.servlet.MyServlet",
paths = { "bin/service/myservlet.json" },

Servlet Defined By Resource Type:

@SlingServlet(

description = "My Servlet",
resourceTypes = { "sling/servlet/default" },
extensions = { "json" },
generateService = true,
generateComponent = true,
metatype = true,
name = "com.example.cq5.servlet.MyServlet",

selectors = { “MyServlet” }

)

Avatar

Level 2

Hi,

As described in my initial reply, registering a Servlet by resource type is the preferred approach in Sling in order to wire rendering logic to requested resources ("resource comes first" approach).  Registering Servlets by path is the traditional Java EE approach where you wire specific rendering logic to static paths ("rendering logic comes first" approach).  Resource type registration in Sling works basically the same way as wiring JSP scripts to resources.

The example that you have provided is not ideal to demonstrate the characteristics of resource type mapping, see the following property:

[...] resourceTypes = { "sling/servlet/default" } [...]

This configuration (i.e. sling/servlet/default) is used for a special case where a Servlet is registered as the so-called "default Servlet". The default Servlet is used when no other rendering script is available for a given request.

Servlets registration for application-specific resource types looks as follows:

[...] resourceTypes = { "myapplication/page/sitemap" } [...]

With the latter, requests to the resource type "myapplication/page/sitemap" are handled by that Servlet, independent of where the resources are located.  Therefore, there is no need for a predefined static path.  Only with resource type registration you fully utilize the dynamic, resource-oriented approach of the Sling framework.  In this context, I recommend reviewing the Sling documentation "URL to Script Resolution" (http://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html) and "Servlets and Scripts" (http://sling.apache.org/documentation/the-sling-engine/servlets.html).

Thanks,
Gregor

Avatar

Correct answer by
Level 2

Hi,

Registering a servlet by resource type is "the Sling way" of doing things, and therefore considered to be the preferred implementation in this context.  Basically it is just an alternative for implementing resource rendering code.  It can be used in the same way as you would use JSP scripts for rendering resources.  You can consider Servlets as a good (or "cleaner") implementation choice when your processing logic outweighs actual rendering logic.

For example, imagine a component that is responsible for creating a sitemap.xml using some form of sophisticated business logic for a global, multi-language site.  The component (and therefore the defined resource) can be placed at different levels of your site.  The component would provide a dialog for various configuration options.  You can then register a Servlet as the default rendering mechanism for your sitemap resource type, so it can read the configuration, process data, and write the XML rendition to the client.

Hope this helps,
Gregor

Avatar

Level 3

Thanks Gregor , I'll go through the references . 

Avatar

Level 1

3 benifits of calling using resourcetype

1. It is sling way

2. If the page that is calling is secured, the servlet is also secured. No need to secure them separately

3. If the servlet needs data from the current page properties, then in case of calling using path, these data has to be passed using servlet. If calling by resourseType, you have access to these properties.