Re: Proxying Resoruces
I've uploaded a first pass patch at SLING-986
I would expect bugs at this stage, but though I should share incase I
was on completely the wrong track.
Ian
On 25 May 2009, at 11:23, Felix Meschberger wrote:
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
Re: Proxying Resoruces
You would need something more than a Proxy Resource Provider, since the Resource, once resolved will give a path, but not invoke any content resolution mechanism. There might be a way of mounting other JCR repositories at locations, but I suspect that a Servlet that binds to a resourceType and then performs the remainder of the proxying over http would be one way of looking at the problem. Bear in mind, anything chatty over a network is going to be slow, a least 1:1 relationship between the request and the onward proxy traffic would be good. Ian On 25 May 2009, at 12:11, Torgeir Veimo wrote: 2009/5/25 Felix Meschberger fmesc...@gmail.com: * external redirects (hard coded support for regular expressions) Slightly unrelated, how would you go about accessing data in an external JCR repository? I assume some sort of proxy resource provider would be necessary? Eg. having user data stored in a separate JCR repository. -- -Tor
Re: Proxying Resoruces
Hi, Ian Boston schrieb: You would need something more than a Proxy Resource Provider, since the Resource, once resolved will give a path, but not invoke any content resolution mechanism. There might be a way of mounting other JCR repositories at locations, but I suspect that a Servlet that binds to a resourceType and then performs the remainder of the proxying over http would be one way of looking at the problem. Bear in mind, anything chatty over a network is going to be slow, a least 1:1 relationship between the request and the onward proxy traffic would be good. Ian On 25 May 2009, at 12:11, Torgeir Veimo wrote: 2009/5/25 Felix Meschberger fmesc...@gmail.com: * external redirects (hard coded support for regular expressions) Slightly unrelated, how would you go about accessing data in an external JCR repository? I assume some sort of proxy resource provider would be necessary? Eg. having user data stored in a separate JCR repository. Hmm, I would say, this would be something for a ResourceProvider, which is mounted into the resource tree and then fetches items from the remote repository serving them as resources. Regards Felix -- -Tor
Re: Proxying Resoruces
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 ?
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 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 ?
[1] https://issues.apache.org/jira/browse/SLING-251
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
Re: Proxying Resoruces
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?
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
Re: Proxying Resoruces
On 25 May 2009, at 11:23, Felix Meschberger wrote: 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 Ok that makes sense, fewer changes. I will work up a patch in the next few days and attach to 251? Or I can push to codereview.appspot.com first (eg http://codereview.appspot.com/14066/show) for comments. Ian
Re: Proxying Resoruces
2009/5/25 Felix Meschberger fmesc...@gmail.com: * external redirects (hard coded support for regular expressions) Slightly unrelated, how would you go about accessing data in an external JCR repository? I assume some sort of proxy resource provider would be necessary? Eg. having user data stored in a separate JCR repository. -- -Tor
Re: Proxying Resoruces
Hi,
Further on this.
Where the url does not contain an extension (eg /_user/private/test1 )
the internal redirect/proxy works, So it works perfectly for a
curl -Ftest=newnode -u admin
http://localhost:8080/_user/private/test1/asdasd/asdasd/asdasd
resulting in creating a node at /_private/D0/33/E2/admin/test1/asdasd/
asdasd and setting the property test.
However, if the url contains an extension, then a 302 is generated
from a streaming servlet, as the target node /_private/D0/33/E2/admin/
test1/asdasd/asdasd doesnt have content subnode... so cant stream.
I think the problem is as a result of the JcrResourceResolver2
resolution process (when combined with my incorrect impl), which sets
the ResourcePathInfo to the as the resolver path is the same as the
request path (ie no path info) so no extensionhence the
streaming servlet.
in my ResourceProvider I am doing.
public Resource getResource(ResourceResolver resourceResolver,
String path) {
// path is /_user/private/test1/asdasd/asdasd/asdasd.html
if (path.startsWith(getBasePath())) {
Session session = resourceResolver.adaptTo(Session.class);
String userId = session.getUserID();
String resourcePath = getResourcePath(userId, path);
// eg /_private/D0/33/E2/admin/test1/asdasd/asdasd
if (resourcePath != null) {
Resource resource = resourceResolver.resolve(resourcePath);
// a JcrNodeResource with metadata sling.resolutionPath=/
_private/D0/33/E2/admin/test1/asdasd/asdasd/asdasd,
sling.resolutionPathInfo=.html
return resource;
}
} else {
LOGGER.info(Base Path doesnt match );
}
return null;
}
Although all of this looks correct to me, I suspect I just should not
be doing it this way... any suggestions ?
Ian
On 21 May 2009, at 16:03, Ian Boston wrote:
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
