Consider a virtual URL configuration in the JcrResourceResolver mapping the URL "/sample" to "/content/some/where/in/the/path.print.a4.html".
When using the URL "/content/some/where/in/the/path.print.a4.html", the resource resolver correctly resolves the "/content/some/where/in/the/path" resource and sets the selector string (print.a4) and extension (html) correctly. When accessing the URL "/sample", the resource is correclty resolved again to "/content/some/where/in/the/path". But the selector string and extension are empty.
The reason for this is the cooperation between the JcrResourceResovler and the SlingRequestPathInfo and the RequestData class. The JcrResourceResolver sets up the Resoure correctly with the ResourceMetadata containing a property sling.resolutionPath set to "/content/some/where/in/the/path". The RequestData.initServlet method uses the Resource (with the correct sling.resolutionPath field) and the servlet request's path info (ServletRequest.getPathInfo()) to find the selectors and extension etc.
The problem with virtual URLs is, that the path info is the originally requested URL – /sample in this case – while the resource resolution path is something completely different. Hence the request path info details cannot be extracted.
To be able to fix this situation, we should add a new field in the ResourceMetadata, which takes the part of the URL path used to resolve the resoure, which is not path of the resource path, such that:
resolutionFullPath = sling.resolutionPath + sling.resolutionPathInfo
The SlingRequestPathInfo class will then only inspoect the sling.resolutionPathInfo field to split that into selectors, extension and suffix.