Overriding Sling DefaultGetServlet.java

Question

I'm working on a servlet to perform some logic specific to a resourceType in sling and set information to the request to be accessible via the jsp then handing off the request to the jsp similarly to the first solution provided in this answer.

Here's some example code to represent my situation:

@SlingServlet(
  resourceTypes="myapp/components/mycomponent",
  methods="GET",
  extensions={"html"}
)
...
  @Reference
  private ServletResolver serlvetResolver;

  protected void doGet(....) {
    setPropertiesToRequest();
    Servlet servlet = servletResolver.resolveServlet(resource, "....jsp");
    servlet.service(slingRequest, slingResponse);
    clearPropertiesFromRequest();
  }

Because of this, I've noticed that I've lost sling's selector handling (I've had to roll my own simpler version to determine which jsp to render. Full featured sling selector handling is described in more detail here). I wanted to reach out to the stack overflow community and ask what else I may be missing out on by depriving the default get handler of the request. I've scanned through the source code but I think there may be more going on.

Secondly, I'd be interested in thoughts on how and where this approach may impact performance of the request resolution.

Thanks, Thomas

score 1 · Answer 1 · answered Jul 18 '14 at 06:42

1

Not sure what you are trying to achieve here, but the main problem seems to me that your SlingServlet handles the html extension and by itself does not have selectors to filter a bit more. Thus it of course intercepts all the requests to your component. Then you have to take care of the selectors again to be able to choose the correct JSP. The question is, why do you use a SlingServlet for it when you anyway do the rendering by JSP? Can't you implement your logic in the JSP or better in a bean referenced in the JSP?

In our company we use our custom tag that takes care of this, but there are public frameworks available from other Adobe Partner:

https://github.com/Cognifide/Slice

http://neba.io/index.html

answered Jul 18 '14 at 06:42

Thomas

6,325
4
30
65

Thank you for responding Thomas. We also were using a tag to instantiate a Java class for the component. However we were setting values directly to the pageContext instead of through a model. Part of this exploration was to bring control over the request completely into Java code and pull logic out of our jsp's for debugging purposes. We aren't concerned with the selector handling at this point because we matched our needs and now have direct control over what the selectors mean. However, we are concerned if we are missing other functionality handled by the default setup. Thanks, Thomas – Thomas Jul 18 '14 at 07:28
As I commented in the other question you linked, maybe a Servlet Filter would be a solution to control the request without interfering too much with the rest of the sling processing. – Thomas Jul 18 '14 at 07:32
I noticed and looked into the filter. The issue there would be that, to prevent the filter from running on every request, we'd have to maintain a whitelist via a regex in the filter. And it would be preferable to keep the logic of whether to run or not in the file with the initialization logic instead of a separate one. If we were running this code on every request, the filter would be a great option though. – Thomas Jul 24 '14 at 14:08

score 1 · Accepted Answer · answered Jul 18 '14 at 09:22

1

Processing the business logic in Java and delegating to scripts for rendering sounds like a job for the recently released Sling Models. Using that should remove the need to implement your own handling of selectors, as those won't affect the model selection, only the rendering scripts.

answered Jul 18 '14 at 09:22

Bertrand Delacretaz

6,100
19
24

Thank you for responding Bertrand. Sling models look like a great option. The issue here is that we were hoping to centralize our logic, including component specific actions with the request, into java (instead of a back and forth between various jsp's and custom tags we define). We are not too concerned with the selector handling as we can reimplement the known required use cases. I mentioned it more so as an example of a feature that we lost with this approach. Our concern is if we are missing out on anything else. Thanks, Thomas – Thomas Jul 24 '14 at 14:24

Overriding Sling DefaultGetServlet.java

2 Answers2