I have to admit, coming from a plain old JavaEE background, I was very dubious over the prospect of not using a Servlet path when creating custom Sling Servlets.  What - no Servlet path?  How will I access my Servlet?  New ideas always go down hard, but once I saw the light, it ALL made sense.

Some folks have been evangelizing the use of Sling Servlets that are resource defined as opposed to path defined.  This idea is not new, nor was it invented or discovered by me.  What was discovered by me was why you would want to do that.  The light came on for me, and I hope this helps it turn on for you.

Blinded by my JavaEE dogma, I initially failed to see the potential impact of defining a Servlet by resource rather than path.  I like familiar.  Its comfortable, predictable, I don't have to guess, it's like a close friend.  This is exactly the kind of state that Einstein described as a killer for continuing to progress intellectually and creatively as we did in our "younger" years.  We depend upon the idea that this is how I have always done it, and its the "right" way.  I am ever trying to move beyond that.  I digress.

So, essentially the difference in definition is:

Servlet Defined By Path:

@SlingServlet(

description = "My Awesome All Powerful Servlet",
generateService = true,
generateComponent = true,
label = "This is the only Servlet you will ever need...",
metatype = true,
methods = { "GET" },
paths = { "/service/awesomeness.json" },
name = "com.example.cq5.servlet.MyAwesomeServlet"

)

Servlet Defined By Resource Type:

@SlingServlet(

description = "My Awesome All Powerful Servlet",
resourceTypes = { "sling/servlet/default" },
extensions = { "json" },
generateService = true,
generateComponent = true,
label = "No, really. THIS is the only Servlet you will ever need...",
metatype = true,
name = "com.example.cq5.servlet.NewerAwesomeServlet",

selectors = { "awesome" }

)

Here is my hit list for why this is preferential.

  1. You have to define a path.  Do I use /bin, /services, /mikekelleher?  What subpath do I use?  What I select will have a knock on effect, described beloow.  I have found, and depending upon how much of a hurry I am in, the choice of path is a bit arbitrary.  I try to be thoughtful in what I select.  This whole issue goes away with resource defined Servlets.
  2. This issue is related to the first.  Depending upon your choice, in CQ 5.5 you may have to configure the Servlet path in the OSGi console.  CQ 5.5 now only opens up a few paths, all others are blocked unless you open them up.  I may have another blog post about how to do that.  This is extra, needless configuration.
  3. This issue is also related to the first 2.  If the service is meant to be "externalized", consumed Client side, you may have to configure the Dispatcher to allow these requests.  Does this open up potential security threats?  This is also extra needless configuration.
  4. Where do I store the path to my service, so that all consumers will know how to "get to me"?  I have long hated this issue.  Do I use a utility class?  Do I "hard code" it into my consumers?  What if I need to change the path?

You can get away with not needing most of these 4 issues when using Resource based Servlets.  You at least need to configure the selectors and the extension, but thats it.  How do you access your new shiny, awesome Servlet?  Here is one example, where I recently needed to consume TimeZone information to be displayed within the Author side creation of content in a ComboBox.  

Pick any page as long as its this one:  /content/geometrixx/en/events/dsc.html.  Fire up your browser and look at that page.  How do you get TimeZone information from that page, you ask?  Change the URL to:  /content/geometrixx/en/events/dsc.timezones.json.  

Now THAT my friends is why you should dump (in addition to the above 4 reasons) path based Servlets.  Any page within your site now becomes a doorway to consume your service.  Its kind of like a free selector for your page component, although the resource it renders is not the page, but the content the service provides.

Enjoy!

PS: No bits, bytes or words were injured during the writing of this article.