Servlet / Script defined by path vs defined by resource | Adobe Higher Education
Skip to main content
K
krisgumm
Level 3
October 16, 2015
Beantwortet

Servlet / Script defined by path vs defined by resource

  • October 16, 2015
  • 6 Antworten
  • 4275 Ansichten

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

    Dieses Thema wurde für Antworten geschlossen.
    Beste Antwort von Gregor_Zurowski

    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

    6 Antworten

    Scott_Brodersen
    Scott_Brodersen
    Level 8
    October 16, 2015

    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

    K
    krisgummAutor
    Level 3
    October 16, 2015

    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
    Gregor_Zurowski
    Level 2
    October 16, 2015

    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
      Gregor_ZurowskiAntwort
      Level 2
      October 16, 2015

      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

      K
      krisgummAutor
      Level 3
      October 16, 2015

      Thanks Gregor , I'll go through the references . 

      gopala97008099
      gopala97008099
      March 21, 2017

      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.

      Allgemeine NutzungsbedingungenAccessibility statement

      Loading footer...