Hi The selector is still present in the request and hence the servlet resolution picks your servlet again.
One option would be for your servlet to implement OptingServlet and in the opting method return true only if the UUID request parameter is present and to otherwise return false. If false is returned, the servlet resolver looks for a different servlet to handle the request. I think another option would be to use the replace selectors feature of the RequestDispatcher (RequestDispatcherOptions IIRC) to remove the selector before forwarding. Yet, I wonder, whether you don’t wand to implement a ResourceProvider for this feature exposed at something like /s so you get URLs like /s/UUID and then you can take UUID and resolve it to the target resource. This way you also ensure proper validation of access control early in the process. Regards Felix > Am 11.02.2015 um 10:38 schrieb anjan <[email protected]>: > > We currently have a custom servlet that is getting invoked based on a > selector. In the servlet, we are looking up the real resource depending on > uuid (jcr:uuid) that is sent in the request. Then we are getting the > request dispatcher using the below call. > > RequestDispatcher dispatcher = request.getRequestDispatcher(newResource); > > Finally, we are calling dispatcher.forward(request, response); > > But, we are getting "org.apache.sling.api.request.RecursionTooDeepException" > and I noticed that my servlet is called in an infinite loop. I am not sure > why this is happening. > > Please note that the path of "newResource" would be something like > "/content/test/abc.txt" (which should be handled by DefaultGetServlet) and > not my custom servlet. > > What am I missing here. Please advice. > > > > -- > View this message in context: > http://apache-sling.73963.n3.nabble.com/RequestDispatcher-tp4047189.html > Sent from the Sling - Users mailing list archive at Nabble.com.
