You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2009/06/02 01:25:14 UTC
JcrResoruceResolver2, by design ?
Hi,
I don't know if this is intentional, but it looks like its not
possible to register more than one ResourceProvider at /, and so its
not possible to bind a ResourceProvider to a node (anywhere in the
content system) with a specific resource type.
Is this intentional or a mistake ?
<Explanation>
The root ResourceProviderEntry, accepts a registration of a provider
registered with /, however all paths as assumed to be relative and so
have the leading / removed, hence the ResourceProvider with a prefix
of / will never match anything, as the path will have already had the
leading / removed.
eg resolving /home/ieb/messagestore/1231231 results in a test against
the default ResourceProviderEntry, the leading / is removed (eg home/
ieb/messagestore/1231231) which does not match the contained
ResourceEntryProvider with a prefix of /
</Explanation>
Checking if the prefix was / before assuming the path is relative
would probably fix the problem.
WDYT ?
Ian
Re: JcrResoruceResolver2, by design ?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 2 Jun 2009, at 16:09, Paul Noden wrote:
> Could you use node representations in store to placehold/redirect to
> the
> nested content at "content/aa/bb/cc/dd/"?
Thank you for you hint, the simple solution appears to be to use a
servlet and request dispatch with a modified Resource, wrapping the
response, throwing away the output and sending redirect to URL of the
created resource ( not the jcr path).
Thanks
Ian
Re: JcrResoruceResolver2, by design ?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 3 Jun 2009, at 06:26, Felix Meschberger wrote:
> Hi Ian,
>
> I could imagine two approaches to your problem:
>
> (1) Register a resource provider for the root node of your "hashed"
> tree. When asked for a resource, it will apply the mapping function to
> find the actual resource.
Felix,
This is the one I am working on, I have a patch that adds a
"classifier" to the registration of a ResourceProvider that allows
more more than one ResourceProvider to be registered per path (but
only one per path/classifier). I don't believe I have this perfect at
the moment since my OSGi container crashes after several reloads
pointing to an unbind problem.
Hashing inside the ResoruceProvider causes all sorts of problems with
recursion especially where the hashed path does not exist in the JCR,
including where the point of recursion is in JcrResourceResolver2.
However a ResoruceProvider that creates a synthetic resource based on
parent sling:resourceType that then triggers a set of servlets bound
to that resource type looks more promising and simpler.
>
>
> (2) Employ the dynamic URL Rewriting patch you proposed in SLING-986:
> You attach that rewriter such that it resoloves and maps as required.
I haven't tried this yet, but I suspect that it might be a better way
of doing it, I was a little concerned about triggering a walk up the
node hierarchy so early in the request lifecycle. (I also think that
the API might need some extra parameters)
>
>
> The advantage of the second approach is, that you have a "free" two-
> way
> mapping for resolving URLs (incoming) and mapping resource paths to
> URLs
> (outgoing).
>
> The disadvantage of both approaches is, that it is actually
> configuration and a simple resource creation à-la
>
> curl -F"sling:resourceType:sakai/store" http://localhost:8080/
> bigstore
>
> might not be enough and you would have some additional functionality
> (a
> listener maybe) to set this up on demand.
I am not certain I understand this bit?
I have found that resourceTypes are not inherited, but that can be
handled in the ResourceProvider or the dynamic mapper.
Thanks for thinking about this.
Ian
>
>
> Regards
> Felix
>
> Ian Boston schrieb:
>>
>> On 2 Jun 2009, at 16:09, Paul Noden wrote:
>>
>>> Hi Ian,
>>>
>>> 2009/6/2 Ian Boston <ie...@tfd.co.uk>
>>>
>>>> AFAICT its impossible to virtualize paths (URI wrt JCR path)
>>>> using this
>>>> approach in the JCR.
>>>>
>>>> Unfortunately for me, its a use case I can't ignore as we have
>>>> lots of
>>>> situations where a non listable could contain millions of items.
>>>> Back to square one.
>>>>
>>>>
>>>>>> The current design and intention is, that for any one (root) path
>>>>>> there
>>>>>> may only be one resource provider registered. So for example,
>>>>>> for a
>>>>>> (root) path "/some/path", there may only one. Of course there
>>>>>> may be
>>>>>> another one at "/some" or at "/some/path/below".
>>>>>>
>>>>>> I want to be able to bind a special Resource to a node with a
>>>>> corresponding resourceType (created by the application) anywhere
>>>>> in the
>>>>> content system, so that all the standard Sling processing can
>>>>> access
>>>>> that
>>>>> Resource.
>>>>>
>>>>> For example:
>>>>> I want to be able to create a node anywhere in the content
>>>>> system, and
>>>>> under that node have a hashed store that is managed as if the
>>>>> entire node
>>>>> space was flattened.
>>>>>
>>>>> eg
>>>>> the URL
>>>>> /x/y/z/store/12312312/a/b/c
>>>>> is mapped to JCR space
>>>>> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c
>>>>>
>>>>> using the ResourceProducer mechanism.
>>>>>
>>>>
>>> Can you go into some more detail regarding the requirements for this
>>> strategy?
>>
>> Paul,
>>
>> Sure,
>> I need to create stores of potentially a large number of items single
>> locations in URL space where the items can be
>> accessed by a URL
>> reference each other.
>> be listed by paged search.
>>
>> The main requirement is that the collection should be addressable
>> with
>> the following form
>> /x/y/z/1001
>>
>> The path might extend further eg
>> /x/y/z/1001/d/e/f
>>
>> the cannonical form being
>> /x/y/z/n/**
>> where n is one of a set of a large number of items (eg 10M)
>>
>> AFAIK, to make this work JCR n needs to be expanded to a hashed
>> tree eg
>> /x/y/z/aa/bb/cc/dd/n/**
>>
>> Having performed the hashing, I would ideally like to reuse the
>> SlingPostServlet and related functionality, so that
>>
>> curl -F"sling:resourceType:sakai/store" http://localhost:8080/
>> bigstore
>>
>> creates a store (identified by the sakai/store resourceType)
>>
>> curl -F"status:stage1" http://localhost:8080/bigstore.create.html
>>
>> a redirect coming back to (ad23415g4 is an opaque token)
>> http://localhost:8080/bigstore/ad23415g4
>>
>> Which can then be used in further operations on that item.
>>
>>
>>>
>>>
>>> Could you use node representations in store to placehold/redirect
>>> to the
>>> nested content at "content/aa/bb/cc/dd/"?
>>
>> Provided that HTTP would never see content/aa/bb/cc/dd/, but I
>> guess by
>> redirect, you mean http redirect, in which case, no since relative
>> URL's
>> break at this point.
>> eg ../ad23415g4/related_information.html
>>
>>
>>>
>>>
>>> Regards,
>>>
>>> Paul Noden
>>
>>
>
Re: JcrResoruceResolver2, by design ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ian,
I could imagine two approaches to your problem:
(1) Register a resource provider for the root node of your "hashed"
tree. When asked for a resource, it will apply the mapping function to
find the actual resource.
(2) Employ the dynamic URL Rewriting patch you proposed in SLING-986:
You attach that rewriter such that it resoloves and maps as required.
The advantage of the second approach is, that you have a "free" two-way
mapping for resolving URLs (incoming) and mapping resource paths to URLs
(outgoing).
The disadvantage of both approaches is, that it is actually
configuration and a simple resource creation à-la
curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore
might not be enough and you would have some additional functionality (a
listener maybe) to set this up on demand.
Regards
Felix
Ian Boston schrieb:
>
> On 2 Jun 2009, at 16:09, Paul Noden wrote:
>
>> Hi Ian,
>>
>> 2009/6/2 Ian Boston <ie...@tfd.co.uk>
>>
>>> AFAICT its impossible to virtualize paths (URI wrt JCR path) using this
>>> approach in the JCR.
>>>
>>> Unfortunately for me, its a use case I can't ignore as we have lots of
>>> situations where a non listable could contain millions of items.
>>> Back to square one.
>>>
>>>
>>>>> The current design and intention is, that for any one (root) path
>>>>> there
>>>>> may only be one resource provider registered. So for example, for a
>>>>> (root) path "/some/path", there may only one. Of course there may be
>>>>> another one at "/some" or at "/some/path/below".
>>>>>
>>>>> I want to be able to bind a special Resource to a node with a
>>>> corresponding resourceType (created by the application) anywhere in the
>>>> content system, so that all the standard Sling processing can access
>>>> that
>>>> Resource.
>>>>
>>>> For example:
>>>> I want to be able to create a node anywhere in the content system, and
>>>> under that node have a hashed store that is managed as if the
>>>> entire node
>>>> space was flattened.
>>>>
>>>> eg
>>>> the URL
>>>> /x/y/z/store/12312312/a/b/c
>>>> is mapped to JCR space
>>>> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c
>>>>
>>>> using the ResourceProducer mechanism.
>>>>
>>>
>> Can you go into some more detail regarding the requirements for this
>> strategy?
>
> Paul,
>
> Sure,
> I need to create stores of potentially a large number of items single
> locations in URL space where the items can be
> accessed by a URL
> reference each other.
> be listed by paged search.
>
> The main requirement is that the collection should be addressable with
> the following form
> /x/y/z/1001
>
> The path might extend further eg
> /x/y/z/1001/d/e/f
>
> the cannonical form being
> /x/y/z/n/**
> where n is one of a set of a large number of items (eg 10M)
>
> AFAIK, to make this work JCR n needs to be expanded to a hashed tree eg
> /x/y/z/aa/bb/cc/dd/n/**
>
> Having performed the hashing, I would ideally like to reuse the
> SlingPostServlet and related functionality, so that
>
> curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore
>
> creates a store (identified by the sakai/store resourceType)
>
> curl -F"status:stage1" http://localhost:8080/bigstore.create.html
>
> a redirect coming back to (ad23415g4 is an opaque token)
> http://localhost:8080/bigstore/ad23415g4
>
> Which can then be used in further operations on that item.
>
>
>>
>>
>> Could you use node representations in store to placehold/redirect to the
>> nested content at "content/aa/bb/cc/dd/"?
>
> Provided that HTTP would never see content/aa/bb/cc/dd/, but I guess by
> redirect, you mean http redirect, in which case, no since relative URL's
> break at this point.
> eg ../ad23415g4/related_information.html
>
>
>>
>>
>> Regards,
>>
>> Paul Noden
>
>
Re: JcrResoruceResolver2, by design ?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 2 Jun 2009, at 16:09, Paul Noden wrote:
> Hi Ian,
>
> 2009/6/2 Ian Boston <ie...@tfd.co.uk>
>
>> AFAICT its impossible to virtualize paths (URI wrt JCR path) using
>> this
>> approach in the JCR.
>>
>> Unfortunately for me, its a use case I can't ignore as we have lots
>> of
>> situations where a non listable could contain millions of items.
>> Back to square one.
>>
>>
>>>> The current design and intention is, that for any one (root) path
>>>> there
>>>> may only be one resource provider registered. So for example, for a
>>>> (root) path "/some/path", there may only one. Of course there may
>>>> be
>>>> another one at "/some" or at "/some/path/below".
>>>>
>>>> I want to be able to bind a special Resource to a node with a
>>> corresponding resourceType (created by the application) anywhere
>>> in the
>>> content system, so that all the standard Sling processing can
>>> access that
>>> Resource.
>>>
>>> For example:
>>> I want to be able to create a node anywhere in the content system,
>>> and
>>> under that node have a hashed store that is managed as if the
>>> entire node
>>> space was flattened.
>>>
>>> eg
>>> the URL
>>> /x/y/z/store/12312312/a/b/c
>>> is mapped to JCR space
>>> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c
>>>
>>> using the ResourceProducer mechanism.
>>>
>>
> Can you go into some more detail regarding the requirements for this
> strategy?
Paul,
Sure,
I need to create stores of potentially a large number of items single
locations in URL space where the items can be
accessed by a URL
reference each other.
be listed by paged search.
The main requirement is that the collection should be addressable with
the following form
/x/y/z/1001
The path might extend further eg
/x/y/z/1001/d/e/f
the cannonical form being
/x/y/z/n/**
where n is one of a set of a large number of items (eg 10M)
AFAIK, to make this work JCR n needs to be expanded to a hashed tree eg
/x/y/z/aa/bb/cc/dd/n/**
Having performed the hashing, I would ideally like to reuse the
SlingPostServlet and related functionality, so that
curl -F"sling:resourceType:sakai/store" http://localhost:8080/bigstore
creates a store (identified by the sakai/store resourceType)
curl -F"status:stage1" http://localhost:8080/bigstore.create.html
a redirect coming back to (ad23415g4 is an opaque token)
http://localhost:8080/bigstore/ad23415g4
Which can then be used in further operations on that item.
>
>
> Could you use node representations in store to placehold/redirect to
> the
> nested content at "content/aa/bb/cc/dd/"?
Provided that HTTP would never see content/aa/bb/cc/dd/, but I guess
by redirect, you mean http redirect, in which case, no since relative
URL's break at this point.
eg ../ad23415g4/related_information.html
>
>
> Regards,
>
> Paul Noden
Re: JcrResoruceResolver2, by design ?
Posted by Paul Noden <no...@nodster.co.uk>.
Hi Ian,
2009/6/2 Ian Boston <ie...@tfd.co.uk>
> AFAICT its impossible to virtualize paths (URI wrt JCR path) using this
> approach in the JCR.
>
> Unfortunately for me, its a use case I can't ignore as we have lots of
> situations where a non listable could contain millions of items.
> Back to square one.
>
>
>>> The current design and intention is, that for any one (root) path there
>>> may only be one resource provider registered. So for example, for a
>>> (root) path "/some/path", there may only one. Of course there may be
>>> another one at "/some" or at "/some/path/below".
>>>
>>> I want to be able to bind a special Resource to a node with a
>> corresponding resourceType (created by the application) anywhere in the
>> content system, so that all the standard Sling processing can access that
>> Resource.
>>
>> For example:
>> I want to be able to create a node anywhere in the content system, and
>> under that node have a hashed store that is managed as if the entire node
>> space was flattened.
>>
>> eg
>> the URL
>> /x/y/z/store/12312312/a/b/c
>> is mapped to JCR space
>> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c
>>
>> using the ResourceProducer mechanism.
>>
>
Can you go into some more detail regarding the requirements for this
strategy?
Could you use node representations in store to placehold/redirect to the
nested content at "content/aa/bb/cc/dd/"?
Regards,
Paul Noden
Re: JcrResoruceResolver2, by design ?
Posted by Ian Boston <ie...@tfd.co.uk>.
Ignore everything I have said :).
It doesnt work,
there is no way of telling if a non existent resource is virtual or
real,
and so AFAICT its impossible to virtualize paths (URI wrt JCR path)
using this approach in the JCR.
Unfortunately for me, its a use case I can't ignore as we have lots of
situations where a non listable could contain millions of items.
Back to square one.
Ian
On 2 Jun 2009, at 09:39, Ian Boston wrote:
>
> On 2 Jun 2009, at 07:02, Felix Meschberger wrote:
>
>> Hi Ian,
>>
>> Ian Boston schrieb:
>>> Hi,
>>>
>>> I don't know if this is intentional, but it looks like its not
>>> possible
>>> to register more than one ResourceProvider at /, and so its not
>>> possible
>>> to bind a ResourceProvider to a node (anywhere in the content
>>> system)
>>> with a specific resource type.
>>>
>>> Is this intentional or a mistake ?
>>
>> The current design and intention is, that for any one (root) path
>> there
>> may only be one resource provider registered. So for example, for a
>> (root) path "/some/path", there may only one. Of course there may be
>> another one at "/some" or at "/some/path/below".
>>
>
>
> Felix,
> Thank you,
> It looks like I am exploiting a loophole in the implementation,
> before I go further should ask how I should achieve what I want to.
>
> I want to be able to bind a special Resource to a node with a
> corresponding resourceType (created by the application) anywhere in
> the content system, so that all the standard Sling processing can
> access that Resource.
>
> For example:
> I want to be able to create a node anywhere in the content system,
> and under that node have a hashed store that is managed as if the
> entire node space was flattened.
>
> eg
> the URL
> /x/y/z/store/12312312/a/b/c
> is mapped to JCR space
> /x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c
>
> using the ResourceProducer mechanism.
>
>
> At the moment, I have a ResourceProducer registered at / that looks
> processes /x/y/z/store/12312312/a/b/c looking for a real parent JCR
> node with a specific sling:resourceType, if found a VirtualResource
> (my own class) is created that has a path of /x/y/z/store/content/aa/
> bb/cc/dd/12312312/a/b/c
>
> Although this works, from what you are saying its a fluke, and will
> not extend to more than one of this type of ResoruceProducer (only
> one can be mapped to each prefix ).
>
> The other worry I have with this approach is that I have to register
> the ResourceProducer at / which means every url is resolved in this
> way.
>
> Is there a better way?
> Ian
>
>
>
>
>>
>> As a consequence, there may only be one resource provider for "/" and
>> this currently is the JcrResourceProvider, which is hard-coded
>> (currently).
>>
>> There is a concept to change the situation with the hard-coded
>> JcrResourceProvider at "/" [1]. But there is no concrete concept or
>> idea
>> yet to allow more than one resource provider fro the exact same
>> (root) path.
>>
>> Hope this helps.
>>
>> Regards
>> Felix
>>
>> [1]
>> http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
>>
>>>
>>>
>>> <Explanation>
>>>
>>> The root ResourceProviderEntry, accepts a registration of a provider
>>> registered with /, however all paths as assumed to be relative and
>>> so
>>> have the leading / removed, hence the ResourceProvider with a
>>> prefix of
>>> / will never match anything, as the path will have already had the
>>> leading / removed.
>>>
>>> eg resolving /home/ieb/messagestore/1231231 results in a test
>>> against
>>> the default ResourceProviderEntry, the leading / is removed (eg
>>> home/ieb/messagestore/1231231) which does not match the contained
>>> ResourceEntryProvider with a prefix of /
>>>
>>> </Explanation>
>>>
>>>
>>> Checking if the prefix was / before assuming the path is relative
>>> would
>>> probably fix the problem.
>>>
>>> WDYT ?
>>> Ian
>>>
>>>
>>>
>
Re: JcrResoruceResolver2, by design ?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 2 Jun 2009, at 07:02, Felix Meschberger wrote:
> Hi Ian,
>
> Ian Boston schrieb:
>> Hi,
>>
>> I don't know if this is intentional, but it looks like its not
>> possible
>> to register more than one ResourceProvider at /, and so its not
>> possible
>> to bind a ResourceProvider to a node (anywhere in the content system)
>> with a specific resource type.
>>
>> Is this intentional or a mistake ?
>
> The current design and intention is, that for any one (root) path
> there
> may only be one resource provider registered. So for example, for a
> (root) path "/some/path", there may only one. Of course there may be
> another one at "/some" or at "/some/path/below".
>
Felix,
Thank you,
It looks like I am exploiting a loophole in the implementation, before
I go further should ask how I should achieve what I want to.
I want to be able to bind a special Resource to a node with a
corresponding resourceType (created by the application) anywhere in
the content system, so that all the standard Sling processing can
access that Resource.
For example:
I want to be able to create a node anywhere in the content system, and
under that node have a hashed store that is managed as if the entire
node space was flattened.
eg
the URL
/x/y/z/store/12312312/a/b/c
is mapped to JCR space
/x/y/z/store/content/aa/bb/cc/dd/12312312/a/b/c
using the ResourceProducer mechanism.
At the moment, I have a ResourceProducer registered at / that looks
processes /x/y/z/store/12312312/a/b/c looking for a real parent JCR
node with a specific sling:resourceType, if found a VirtualResource
(my own class) is created that has a path of /x/y/z/store/content/aa/
bb/cc/dd/12312312/a/b/c
Although this works, from what you are saying its a fluke, and will
not extend to more than one of this type of ResoruceProducer (only one
can be mapped to each prefix ).
The other worry I have with this approach is that I have to register
the ResourceProducer at / which means every url is resolved in this way.
Is there a better way?
Ian
>
> As a consequence, there may only be one resource provider for "/" and
> this currently is the JcrResourceProvider, which is hard-coded
> (currently).
>
> There is a concept to change the situation with the hard-coded
> JcrResourceProvider at "/" [1]. But there is no concrete concept or
> idea
> yet to allow more than one resource provider fro the exact same
> (root) path.
>
> Hope this helps.
>
> Regards
> Felix
>
> [1]
> http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
>
>>
>>
>> <Explanation>
>>
>> The root ResourceProviderEntry, accepts a registration of a provider
>> registered with /, however all paths as assumed to be relative and so
>> have the leading / removed, hence the ResourceProvider with a
>> prefix of
>> / will never match anything, as the path will have already had the
>> leading / removed.
>>
>> eg resolving /home/ieb/messagestore/1231231 results in a test against
>> the default ResourceProviderEntry, the leading / is removed (eg
>> home/ieb/messagestore/1231231) which does not match the contained
>> ResourceEntryProvider with a prefix of /
>>
>> </Explanation>
>>
>>
>> Checking if the prefix was / before assuming the path is relative
>> would
>> probably fix the problem.
>>
>> WDYT ?
>> Ian
>>
>>
>>
Re: JcrResoruceResolver2, by design ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Ian,
Ian Boston schrieb:
> Hi,
>
> I don't know if this is intentional, but it looks like its not possible
> to register more than one ResourceProvider at /, and so its not possible
> to bind a ResourceProvider to a node (anywhere in the content system)
> with a specific resource type.
>
> Is this intentional or a mistake ?
The current design and intention is, that for any one (root) path there
may only be one resource provider registered. So for example, for a
(root) path "/some/path", there may only one. Of course there may be
another one at "/some" or at "/some/path/below".
As a consequence, there may only be one resource provider for "/" and
this currently is the JcrResourceProvider, which is hard-coded (currently).
There is a concept to change the situation with the hard-coded
JcrResourceProvider at "/" [1]. But there is no concrete concept or idea
yet to allow more than one resource provider fro the exact same (root) path.
Hope this helps.
Regards
Felix
[1]
http://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html
>
>
> <Explanation>
>
> The root ResourceProviderEntry, accepts a registration of a provider
> registered with /, however all paths as assumed to be relative and so
> have the leading / removed, hence the ResourceProvider with a prefix of
> / will never match anything, as the path will have already had the
> leading / removed.
>
> eg resolving /home/ieb/messagestore/1231231 results in a test against
> the default ResourceProviderEntry, the leading / is removed (eg
> home/ieb/messagestore/1231231) which does not match the contained
> ResourceEntryProvider with a prefix of /
>
> </Explanation>
>
>
> Checking if the prefix was / before assuming the path is relative would
> probably fix the problem.
>
> WDYT ?
> Ian
>
>
>