Servlet / Script defined by path vs defined by resource

[krisgumm]

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

[Scott_Brodersen]

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

[krisgumm]

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” }

)

[Gregor_Zurowski]

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

[Gregor_Zurowski · Accepted solution]

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

[krisgumm]

Thanks Gregor , I'll go through the references . 

[gopala97008099]

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.