Hi,
Ian Boston schrieb:
> Felix,
> Inline:
> On 25 May 2009, at 09:22, Felix Meschberger wrote:
>
>> Hi Ian,
>>
>> Replying to this, though I only completely understood your request after
>> reading your second post.
>>
>> So what you really want is, that if a request comes in prefixed with
>>
>> /_user/private/
>>
>> to be redirected to
>>
>> /_private/-some-path-/private/
>>
>> where -some-path- is dynamic and includes the user id of the current
>> user. Right ?
>
> yes, internally redirected as the /system/userManager/user/ieb does,
> but, using normal content space.
>
>>
>>
>> This sounds similar to an earlier issue, which I recently closed
>> SLING-251 [1]. I closed this because it is rather old. In addition
>> resolving some prefix (be it "~" or "/_user/private") depends heavily on
>> how "user home" locations are managed. And this is outside of the scope
>> of the ResourceResolver.
>
> I agree, user home is a jcr management/instanace deployment issue.
> The use cases for this are not limited just to users, any content tree
> that is predicted to result in a URL path where there are millions of
> direct children.
> eg messaging inbox.
>
> and where we don't want to expose the storage structure in the url (ie
> want inbox/231243123 not inbox/2009/01/23/12/231243123 )
> and where we do not want to list the children. (except by search with
> paging)
>
> or where we simply want to abstract the binding between url and storage.
>
>>
>>
>> I could imaging a plugable solution, though, in that for example we
>> enhance the mapping functionality of the ResourceResolver2. Currently
>> there is such functionality to generate internal or external redirects
>> based on configuration in /etc/map.
>>
>> We could extend this such, that it would be possible to bind a service
>> to such a configuration: the configuration value is an OSGi filter
>> expression to be used with the BundleContext.getServiceReference(String
>> name, String filter) method.
>>
>> In addition a service interface would be defined:
>>
>> public interface MappingResolver {
>> ResultType resolve(HttpServletRequest, String);
>> ResultType map(HttpServletRequest, String);
>> }
>>
>> Configuration would be
>>
>> /etc/map/http/myhost/~
>> -> sling:mapper = "(prefix='~')"
>>
>> This would use the MappingResolver service registered with a
>> registration property "prefix" set to "~".
>>
>> This would allow you to register a MappingResolver service for
>> /_user/private and have it called to resolve requests to /_user/private
>> and also to have it called for creating the URL when calling the
>> ResourceResolver.map method.
>>
>> WDYT ?
>
>
> Yes I think that would do it, and provide a simpler extension point.
>
> In the end I have created a VirtualResource and
> AbstractVirturalResourceProvider[1] that make it possible for
> ResourceResolvers to wrap any other resolved Resource, the only bit I
> wasn't getting was to ensure that the VirtualResource did not have its
> RequestPathInfo re computed.
>
> Obviously the advantage of the Resource approach is ( I think, not
> tested) that the ResourceProvider can bind to a resourceType anywhere in
> the content system, the advantage of the /etc/map approach is that it
> can be configured at runtime.
>
> I suspect I am going to want more flexibility in the re-writer so would
> be happy to help. Some of our sys admins love httpd mod_rewrite and will
> pounce on that level of functionality.
>
> Would you make all of the /etc/map resolution go through the plugin
> interface by making the existing code implement that interface?
Implementation wise, the MapEntry would probably be extended to support
calling the new service API instead of using configured patterns to
return the mapped path.
So this would be more or less transparent and each entry below /etc/map
could effectively be either of
* internal redirect (hard coded support for regular expressions)
* external redirects (hard coded support for regular expressions)
* service API call
Regards
Felix
>
> Ian
>
>
>>
>>
>> [1] https://issues.apache.org/jira/browse/SLING-251
>
> Reading the comments:
> We have the use case for /~ implemented[2] already with the
> VirtualResource approach, and the use case for /~ieb [3]
> All of the SlingDefaultServlet methods appear to work as we are just
> providing a Resource
>
> [1]
> http://github.com/ieb/open-experiments/tree/3c1a92784b8f3e0856e6e4aae623d52343f150c7/slingtests/osgikernel/bundles/virtual
>
> [2]
> http://github.com/ieb/open-experiments/blob/3c1a92784b8f3e0856e6e4aae623d52343f150c7/slingtests/osgikernel/bundles/personal/src/main/java/org/sakaiproject/kernel/personal/PersonalPrivateResourceProvider.java
>
> [3]
> http://github.com/ieb/open-experiments/blob/3c1a92784b8f3e0856e6e4aae623d52343f150c7/slingtests/osgikernel/bundles/personal/src/main/java/org/sakaiproject/kernel/personal/PersonalPublicResourceProvider.java
>
>
>>
>>
>> Ian Boston schrieb:
>>> Hi,
>>>
>>> Is it possible to internally Proxy an existing Sling Resource from
>>> another ResourceProvider ?
>>>
>>> eg
>>>
>>> I have a PrivateResourceProvider that matches /_user/private
>>>
>>> From that it builds a path based on the logged in user and the rest of
>>> the url
>>> eg
>>> /_private/A3/D0/33/admin
>>>
>>> eg
>>> /_user/private/test1.html
>>> results in
>>> /_private/A3/D0/33/admin/test1.html
>>>
>>> at that point I would like to internally get hold of the resource for
>>> /_private/A3/D0/33/admin/test1.html and return with that from the
>>> PrivateResourceProvider so that it handles everything. But, I get an
>>> external redirect (302) to _private/A3/D0/33/admin/test1.html
>>>
>>> Ian
>>>
>>>
>>>
>
>
