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/10/08 11:25:09 UTC
Question about order of ResourceProvider registration
Hi,
I notice that ResourceProvidersEntries are sorted by the prefix that
they use. (there is a TreeMap in ResourceProviderEntries for entries)
I also notice that if they are not ordered in that way lots of things
start to break. This appears a bit fragile. I assume it relies on GET
and POST appearing in a set order.
Is the sort ordering correct ?
Was this intentional or fortunate ?
Thanks
Ian
Re: Question about order of ResourceProvider registration
Posted by Ian Boston <ie...@tfd.co.uk>.
On 8 Oct 2009, at 21:08, Felix Meschberger wrote:
>>
>> ok, this is where the patch is upto (Map of Maps), I think the
>> ordering
>> may be the last problem, but I thought that several days ago.
>
> I don't think that ordering is an issue if we are talking about map of
> maps indexed by path segment - we might do an implicit order by
> registration time as would be done by a regular LinkedHashMap.
Ok, will do, I have a feeling that simply providing a Comparitor and
the right type of map impl will create the right order.
I'll re-push the patch set when I have something thats solid and works.
I might even try and get some comparative evidence :)
Ian
Re: Question about order of ResourceProvider registration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Ian Boston schrieb:
>
> On 8 Oct 2009, at 11:18, Felix Meschberger wrote:
>
>> Hi,
>>
>> Ian Boston schrieb:
>>> Hi,
>>> I notice that ResourceProvidersEntries are sorted by the prefix that
>>> they use. (there is a TreeMap in ResourceProviderEntries for entries)
>>> I also notice that if they are not ordered in that way lots of things
>>> start to break. This appears a bit fragile. I assume it relies on GET
>>> and POST appearing in a set order.
>>>
>>> Is the sort ordering correct ?
>>
>> I assume you mean the TreeSet in the
>> ResourceProviderEntry.addResourceProvider method ? I could not find
>> another location matching your description.
>
> Yes sorry, TreeSet and yes, in that method.
>
>>
>>> Was this intentional or fortunate ?
>>
>> But yes, it is intended that the ResourceProviderEntry elements in the
>> entries field is sorted.
>>
>> To be honest ... I fail to remember why the ordering was important, I
>> just know it was (and still seems to be) important for correct operation.
>
> ok.
>
>>
>> Carsten and I have once been discussing off-line that it might be
>> tempting to check whether refactoring this structure into a Map of Maps
>> of Maps of Entries would help performance wise ... but we never came
>> around to testing it or to more investigation.
>
> ok, this is where the patch is upto (Map of Maps), I think the ordering
> may be the last problem, but I thought that several days ago.
I don't think that ordering is an issue if we are talking about map of
maps indexed by path segment - we might do an implicit order by
registration time as would be done by a regular LinkedHashMap.
>
> I think its quicker, but I don't have hard evidence.
That's what we suppose, too -- and we don't have hard evidence either ...
> it certainly doesn't loop or recurse quite as much and most of the
> lookups are split the path into elements and do a tree walk, so it
> degrades by the number of levels rather than the number of providers.
> (assuming efficient maps)
>
> Sounds like I should continue.
Most probably, yes.
Regards
Felix
> Ian
>
>
>>
>> Regards
>> Felix
>
>
Re: Question about order of ResourceProvider registration
Posted by Ian Boston <ie...@tfd.co.uk>.
On 8 Oct 2009, at 11:18, Felix Meschberger wrote:
> Hi,
>
> Ian Boston schrieb:
>> Hi,
>> I notice that ResourceProvidersEntries are sorted by the prefix that
>> they use. (there is a TreeMap in ResourceProviderEntries for entries)
>> I also notice that if they are not ordered in that way lots of things
>> start to break. This appears a bit fragile. I assume it relies on GET
>> and POST appearing in a set order.
>>
>> Is the sort ordering correct ?
>
> I assume you mean the TreeSet in the
> ResourceProviderEntry.addResourceProvider method ? I could not find
> another location matching your description.
Yes sorry, TreeSet and yes, in that method.
>
>> Was this intentional or fortunate ?
>
> But yes, it is intended that the ResourceProviderEntry elements in the
> entries field is sorted.
>
> To be honest ... I fail to remember why the ordering was important, I
> just know it was (and still seems to be) important for correct
> operation.
ok.
>
> Carsten and I have once been discussing off-line that it might be
> tempting to check whether refactoring this structure into a Map of
> Maps
> of Maps of Entries would help performance wise ... but we never came
> around to testing it or to more investigation.
ok, this is where the patch is upto (Map of Maps), I think the
ordering may be the last problem, but I thought that several days ago.
I think its quicker, but I don't have hard evidence.
it certainly doesn't loop or recurse quite as much and most of the
lookups are split the path into elements and do a tree walk, so it
degrades by the number of levels rather than the number of providers.
(assuming efficient maps)
Sounds like I should continue.
Ian
>
> Regards
> Felix
Re: Question about order of ResourceProvider registration
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Ian Boston schrieb:
> Hi,
> I notice that ResourceProvidersEntries are sorted by the prefix that
> they use. (there is a TreeMap in ResourceProviderEntries for entries)
> I also notice that if they are not ordered in that way lots of things
> start to break. This appears a bit fragile. I assume it relies on GET
> and POST appearing in a set order.
>
> Is the sort ordering correct ?
I assume you mean the TreeSet in the
ResourceProviderEntry.addResourceProvider method ? I could not find
another location matching your description.
> Was this intentional or fortunate ?
But yes, it is intended that the ResourceProviderEntry elements in the
entries field is sorted.
To be honest ... I fail to remember why the ordering was important, I
just know it was (and still seems to be) important for correct operation.
Carsten and I have once been discussing off-line that it might be
tempting to check whether refactoring this structure into a Map of Maps
of Maps of Entries would help performance wise ... but we never came
around to testing it or to more investigation.
Regards
Felix