Sam- Regardless of whether it is a JSP or Servlet, the correct way to handle this is to create a node with a sling:resourceType property. Your JSP or Servlet should be associated with that resource type. If you need to secure the content, secure the content, but that's an orthogonal concern to the scripts used to render the content. Mounting a servlet at a particular path is sometimes necessary and appropriate, but more often than not it is something you can and should avoid. And, as you note, this puts the onus of security on your servlet, not the repository.
To your question about integration tests, most of the integration tests I write run in Maven and interact with servlets/scripts running inside Sling via HTTP. I try not to write test-specific servlets to the greatest extent possible. We obviously need to create test services for testing the framework itself, but not for applications running inside of the framework. I also try to focus on writing unit tests with good mocks as those tend to be significantly faster than integration tests. YMMV, of course. Justin On Fri, Jan 27, 2012 at 1:33 PM, sam ” <[email protected]> wrote: > Hey, > > I have a test script that will make a series of HTTP requests to Sling. > I need to write servlets that will handle the requests. > I can either use jsp (/apps/tests/test1/json.jsp, for example). > Or, I can write a @Service that implements Servlet interface. > > Good thing about writing .jsp to the repository is that I can configure ACL > to block access to /apps/tests. > If I write a @Service that implements Servlet interface (that handles > requests to /bin/tests, for example), anonymous users can make requests. > Maybe there is a way to configure ACL for resources that do not exist in > the repository (such as /bin/tests) ?? > > How do you write integration tests? > > Thanks. > Sam.
