Hi @test1234567!
Looking at your url example "www.company.com/apps/test/product/value1/value2" it is not quite clear where your servlet path ends and the "parameters" you want to retrieve start - at least to the used API that's unclear.
Please refer to the Sling API documentation about URL decomposition. A URL may have the following parts:
- Resource Path
- Selectors
- Extension
- Suffix
Your example url has only the first, a resource path (because there are not dots present). There are no selectors, no extension and there isn't a suffix. Please note the hint from the above mentioned documentation page on suffixes:
"Note, that after the resource path at least a dot must be in the URL to let Sling detect the suffix."
That's why your first approach using .getSuffix() does not work.
I'm not 100% sure about your second approach but it will probably not work because your path is only registered for the servlet (and only the first part of it) and there is no real resource present at that path in the repository.
A simple solution to your issue would be to add an extension to your serlvet, e. g. binding it to:
This way Sling will be able to correctly identify the suffix properly and .getSuffix() will give you "/value1/value2".
However, from an architectural perspective I recommend to reevaluate your approach:
- Why are you binding the servlet to a fixed path?
This has a couple of implications and is therefore not recommended for the majority of use cases. There are some edge cases where binding a servlet to a path may be necessary of beneficial but in my experience that's almost never the case. Please see this documentation for additional information on the caveats/drawbacks when binding servlets by path. - Why are you trying to pass parameters as a suffix?
This depends on your application architecture, but from the information share this does not look ideal to me. What's the reason/requirement behind this decision? If you need to pass parameters, there are two common approaches:- Query-Parameters: This is the "classic" way to go if you don't want/need to cache the pages (as query parameters will cause the dispatcher to not cache these requests). It's commonly used, e. g. for search queries or similar, dynamic requests.
- Selectors: selectors can be used quite similar to query parameters but allow caching on the dispatcher. There are some things to keep in mind (number of variations, order of selectors, etc.) but they all apply to suffixes as well, so these are not disadvantages compared to your current approach.
Hope that helps!