Hi Sandro, ups, yeah I meant to register a script - I thought I had seen servlet resources in the jcr explorer when I last checked - but I might be mistaken. If the servlet wins, then my approach clearly doesn't work....so actually I think the ResourceDecorator is really the way to go :) Actually, the decorate(Resource) method should be called. And you should be able to check for the original selector there as well - the only difference should be that you can distinguish between the original request resource and maybe others which get resolved later...maybe this is the problem? If that's the case we really should think about this deprecation again.
Carsten 2012/4/17 Sandro Boehme <[email protected]>: > Hi Carsten, > > I already looked at the jcr explorer and tried to create patches but decided > to write something new. The jcr explorer cannot display servlet resources > because the servlet path wins there too. > What was your suggestion from two days ago? The crucial word of your > explanation got lost on the way to the mailing list. ;-) "register a <?> for > the selector" > Regarding the deprecation: I don't care about the time frame, I just > expected semantic versioning. But it wouldn't change something in my case > :-). > > Best, > > Sandro > > Am 17.04.12 08:40, schrieb Carsten Ziegeler: > >> Hi Sandro, >> >> yes, I think the deprecation and removal was really done in a short >> timeframe. >> >> You might want to have a look at the jcr explorer we have in Sling - I >> think it does exactly the same as you are trying by using a selector - >> so you might be able to just copy that stuff. >> Or you could of course send patches for Sling's explorer if something >> is missing :) >> >> Regards >> Carsten >> >> 2012/4/16 Sandro Boehme<[email protected]>: >>> >>> Hi Carsten, >>> >>> thanks for taking the time to answer my post. >>> If you meant registering a servlet and using >>> >>> http://sling.apache.org/apidocs/sling6/org/apache/sling/api/SlingHttpServletRequest.html#getRequestDispatcher(org.apache.sling.api.resource.Resource) >>> to include or forward to my JSP I will try that again differently as it >>> didn't get interpreted the last time. It has just been shown as content. >>> >>> My use case is basically that I'm writing a Sling based JCRBrowser. It >>> also >>> shows the servlet resources of Sling's virtual resource tree. One goal >>> is, >>> to make every resource bookmarkable. The user should be able to click on >>> the >>> link for a servlet resource and see it's properties in the JCRBrowser. >>> Even >>> though there are not many. But if he does that he will get directed to >>> the >>> servlet itself which will interpret the resource and not to my script. I >>> solved that with a ResourceDecorator checking if the pathInfo of the URL >>> ends with my selector. But it seems like that functionality got >>> deprecated >>> and removed between minor versions. >>> >>> Thanks, >>> >>> Sandro >>> >>> Am 15.04.12 18:47, schrieb Carsten Ziegeler: >>> >>>> Hi, >>>> >>>> I'm not sure if I understand your use case correctly, however the >>>> simplest solution which comes to my mind is to register a for the >>>> selector and then do an include with the new resource type. >>>> >>>> Carsten >>>> >>>> 2012/4/10 Sandro Boehme<[email protected]>: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I used the org.apache.sling.api.resource.ResourceDecorator service in >>>>> version 2.2.3-SNAPSHOT to be able to render servlet resources from >>>>> servlets >>>>> that have been registered by path with my script (and not with the >>>>> servlets >>>>> themselfs). I did that by using the request from decorate(Resource, >>>>> HttpServletRequest) to check whether it ends with my selector. If thats >>>>> the >>>>> case I return a ResourceWrapper whose resource type returns the one for >>>>> my >>>>> script. >>>>> I've seen that in the latest trunk (version 2.2.5-SNAPSHOT of >>>>> org.apache.sling.api) this method is deprecated and will never get >>>>> called. >>>>> >>>>> Is there an other way to accomplish my goal now? >>>>> >>>>> Best, >>>>> >>>>> Sandro >>>> >>>> >>>> >>>> >>>> >>> >> >> >> > -- Carsten Ziegeler [email protected]
