sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: JcrResoruceResolver2, by design ?
Date Tue, 02 Jun 2009 14:56:50 GMT
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
>>>
>>>
>>>
>


Mime
View raw message