Hi Carsten,
Am 17.04.12 18:11, schrieb Carsten Ziegeler:
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.
There are no servlets, but the scripts are located in a path containing
"servlet". I use the same approach.
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
Thats it! Thanks for your valuable hint! I tried that method as it got
called but I didn't see
resource.getResourceMetadata().getResolutionPathInfo()
which matches exactly ".jcrbrowser.view.html"
Just for the record (you probably know that):
The definition of the resolution path info is:
"The name of the required property providing the part of the request URI
which was not used to the resolve the resource to which the meta data
instance belongs (value is "sling.resolutionPathInfo"). The value of
this property concatenated to the value of the sling.resolutionPath
property returns the original request URI leading to the resource.
This property is optional. If missing, it should be assumed equal to an
empty string."
Which sounds semantically equal to the definition of the pathInfo in the
servlet spec:
"The part of the request path that is not part of the Context Path or
the Servlet Path.
...
requestURI = contextPath + servletPath + pathInfo"
The Sling resolutionPath is defined as "The name of the required
property providing the part of the request URI which was used to the
resolve the resource to which the meta data instance belongs."
This makes me confident that it is stable to use the resolutionPathInfo
to check if it matches my script selector and extension.
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
Thanks,
Sandro
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
