Also lastly to combine with my previous mail, it doesn’t have to be only
images. It could also be pdf’s, zips,… So the approach I am using now won’t
work in all the cases I want :)
> On 28 Jul 2016, at 23:44, Roy Teeuwen <r...@teeuwen.be> wrote:
>
> Hey Jason, Olivier,
>
> @Jason:
> Damn, I feel so stupid now :D indeed, using
> /content/dam/nice-image.jpg.cdn./modification-date/20160815/nice-image.jpg
> fixes everything. I don’t have to implement the nonexistingservlet anymore
> ;), I was indeed thinking that jpg was the extension and so that the cdn HAD
> to be before the jpg because else the cdn would be the extension, but your
> explanation makes sense!
>
> @Olivier:
> "What's the reason for forwarding instead of reading/serving the resource
> from the repository in your current servlet?” Currently I am doing it like
> that, but I find the implementation a bit nasty… See how I did it:
>
> @Override
> protected void doGet(SlingHttpServletRequest request,
> SlingHttpServletResponse response) throws ServletException, IOException {
> Resource resource = request.getResource();
> final Image image = new Image(resource);
> image.set(Image.PN_REFERENCE, resource.getPath());
> try {
> final String mimeType = image.getMimeType();
> final Layer layer = image.getLayer(false, false, false);
> double quality = mimeType.equals(MIME_TYPE_GIF) ? 255 : 1.0;
> response.setContentType(mimeType);
> layer.write(mimeType, quality, response.getOutputStream());
> response.getOutputStream().flush();
> } catch (RepositoryException e) {
> LOG.error("could not get layer", e);
> }
> }
>
> Thats why I would think it would be easier / nicer to just forward it to the
> normal jpg handling servlet so that I don’t actually have to manually write
> it to the servlet response output. If there is a better way in serving the
> image resource from the repo, do tell :D.
>
> (For when you might be curious on why I am doing all of this, I am adding the
> latest modification date to all the image urls because the image urls
> actually get served by a cdn in front that proxies to the dam:
> https://some.azureedge.net/content/dam/nice-image.jpg.cdn./modification-date/20160815/nice-image.jpg
>
> <https://some.azureedge.net/content/dam/nice-image.jpg.cdn./modification-date/20160815/nice-image.jpg>
> , this way when the same image gets replaced in the dam by a new image with
> the same name on a page, I don’t have to invalidate the azure cdn cache
> because the modification date changing in the url takes care of that, and
> because I am not using a query string I also don’t have to care about
> nullifying the browser client-side caching)
>
> Thanks so far!
> Greets,
> Roy
>
>
>> On 28 Jul 2016, at 23:02, Jason Bailey <jason.bai...@sas.com
>> <mailto:jason.bai...@sas.com>> wrote:
>>
>> I was going to say that you shouldn't need to implement NonExistingResource
>> interface because a selector wouldn't impact resolution then I had one of
>> those blinding aha moments.
>>
>> In the case of the url you posted you aren't adding a selector, you are
>> modifying the resource name. '/content/dam/nice-image.jpg' does not have an
>> extension in the traditional sense, in the traditional sling sense the
>> resource would actually be '/content/dam/nice-image' and jpg would be a
>> handler that would return the asset as a jpeg.
>>
>> So when you are adding a selector to it it's not matching anything because
>> there is no '/content/dam/nice-image' resource to match against.
>>
>> So first make your request find the resource without the servlet in the way.
>> If you switch around the .cdn to the end and add a period at the end of cdn
>> like this...
>>
>> content/dam/nice-image.jpg.cdn./modification-date/20160815/nice-image.jpg
>>
>> This should work to return the original nice-image.jpg at that point it
>> should be easier to create a servlet that will have the resource as part of
>> the request.
>>
>> Or optionally you could try adding a sling:resourceType to the image and
>> have a selector within that resource type that does what you need it do.
>>
>> -Jason
>>
>>
>>
>> -----Original Message-----
>> From: Roy Teeuwen [mailto:r...@teeuwen.be <mailto:r...@teeuwen.be>]
>> Sent: Thursday, July 28, 2016 3:17 PM
>> To: users@sling.apache.org <mailto:users@sling.apache.org>
>> Subject: Re: Getting the actual resource from a request
>>
>> Hmm Sorry Jason,
>>
>> I might have had to notice that I am extending SlingSafeMethodServlet but
>> also implementing the following servlet:
>> https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/day/cq/commons/servlets/NonExistingResourceServlet.html
>>
>> <https://docs.adobe.com/docs/en/cq/5-6-1/javadoc/com/day/cq/commons/servlets/NonExistingResourceServlet.html>
>>
>> And as it states in the docs itself, it also says:
>> public boolean accepts(SlingHttpServletRequest request) {
>> // get non-existing path (incl. selectors and extension!)
>> String path = request.getResource().getPath();
>> // return true if this servlet can handle this path
>> return true;
>> }
>>
>> So probably it’s not possible to do it through this interface in without
>> manually parseing :) It also says in the docs: Please note: This is a
>> temporary solution until Sling provides a built-in mechanism for this use
>> case. Not to be used by client implementations!
>>
>> Any clue if it is possible yet to do it with standard sling, the thing I try
>> to achieve is a servlet that also catches resources with a selector AND
>> suffix (as stated in my example of course) ?
>>
>> Thanks!
>> Roy
>>
>>
>>> On 28 Jul 2016, at 18:35, Jason Bailey <jason.bai...@sas.com> wrote:
>>>
>>> I'm under the understanding that it is;
>>>
>>> request.getResource().getPath()
>>>
>>> -----Original Message-----
>>> From: Roy Teeuwen [mailto:r...@teeuwen.be]
>>> Sent: Thursday, July 28, 2016 12:31 PM
>>> To: users@sling.apache.org
>>> Subject: Getting the actual resource from a request
>>>
>>> Hey all,
>>>
>>> I am creating a SlingServlet that will work by both using a selector
>>> and a suffix. The resource is for example /content/dam/image.jpg and
>>> the actual url will be
>>> /content/dam/nice-image.cdn.jpg/modification-date/20160815/nice-image.
>>> jpg
>>>
>>> What is the most easy way to get the actual resource path again from the
>>> SlingHttpServletRequest? Currently I am doing the following but I find it a
>>> bit cumbersome:
>>>
>>> private String getResourcePath(SlingHttpServletRequest request) {
>>> String requestUrl = request.getRequestPathInfo().getResourcePath();
>>> int endIndex =
>>> requestUrl.lastIndexOf(request.getRequestPathInfo().getSuffix());
>>> String resourcePathWithSelector = requestUrl.substring(0, endIndex);
>>> endIndex =
>>> resourcePathWithSelector.lastIndexOf(request.getRequestPathInfo().getSelectorString()
>>> + "." + request.getRequestPathInfo().getExtension());
>>> return resourcePathWithSelector.substring(0, endIndex) +
>>> request.getRequestPathInfo().getExtension();
>>> }
>>>
>>> Is there an easier way or is parsing it like this the only way?
>>>
>>> Also after I got the actual resourcePath, I tried doing the following, but
>>> this doesn’t seem to work, any clue on why?
>>>
>>> @Override
>>> protected void doGet(SlingHttpServletRequest request,
>>> SlingHttpServletResponse response) throws ServletException, IOException {
>>> RequestDispatcherOptions opts = new RequestDispatcherOptions();
>>> opts.setReplaceSelectors("");
>>> String resourcePath = getResourcePath(request);
>>> RequestDispatcher dispatcher =
>>> request.getRequestDispatcher(resourcePath, opts);
>>> if (dispatcher != null) {
>>> dispatcher.forward(request, response);
>>> }
>>> }
>>>
>>> I would expect that the previous would actually just forward it to the
>>> actual image being fetched from the getResourcePath but it just gives
>>> me a 404 not found (I checked the getResourcePath and it does return
>>> /content/dam/nice-image.jpg)
>>>
>>> Thanks!
>>> Roy
>>
>
