Hi,
This is already the case because all resource providers on a certain
level are ordered according to their ServiceReference.compareTo. Thus
the service.ranking and service.id are considered for the ordering.
Regards
Felix
On 24.08.2010 17:52, Carsten Ziegeler wrote:
Mike Müller wrote
Hi
Hi,
On 24.08.2010 09:51, Julian Sedding wrote:
Hi Felix
The proposal looks good, +1. I've some additional thoughts:
If resources are provided by several ResourceProviders, does it matter
which one provides the resource? E.g. the sling:resourceType might
vary. So I believe that the order
Hi,
Here is what I would see to be intended.
For case (1) the ResourceResolver must mix the results of calling
listChildren(/for/bar) on all resource providers providing resource at
or below said path. In this case the BundleResourceProvider and the
JcrResourceProvider.
For case (2) the
Hi
That's exactly what I was thinking of: Not the Resource Provider
implementations should be responsible for the synthetic resources
but the ResourceResolver implementation.
So a big +1 from my side.
best regards
mike
Hi,
Here is what I would see to be intended.
For case (1) the
Hi Felix
The proposal looks good, +1. I've some additional thoughts:
If resources are provided by several ResourceProviders, does it matter
which one provides the resource? E.g. the sling:resourceType might
vary. So I believe that the order in which ResourceProviders are asked
to provide a
Hi
That seems to be a good way to implement it. IIRC the resource providers
are called in order starting with the provider which is registered
for the longest part of the requested path. If that is correct the
SyntheticResourceProvider (which I rather would name something like
PathNodeProvider)
Mike Müller wrote
Hi
That seems to be a good way to implement it. IIRC the resource providers
are called in order starting with the provider which is registered
for the longest part of the requested path. If that is correct the
SyntheticResourceProvider (which I rather would name something
Case 1 should be working in trunk now. What's the
Sling-Bundle-Resources header look like?
In terms of case 2, if this was to be implemented, I don't think it
should be up to the ResourceProvider implementation to create the
SyntheticResource. If a ResourceProvider has a root of /foo/bar, then it
Subject: Re: [DISCUSS] Correct listing of resource children (follow up
to SLING-1672)
Case 1 should be working in trunk now. What's the
Sling-Bundle-Resources header look like?
In terms of case 2, if this was to be implemented, I don't think it
should be up to the ResourceProvider implementation
I can confirm that case 1) does work.
If a ResourceProvider has a root of
/foo/bar, then it
shouldn't be expected to return resources for anything not
starting with /foo/bar.
agree, but in case of listChildren on any
path/node/resource we could consult all resource providers
(which
, August 23, 2010 7:56 PM
To: 'dev@sling.apache.org'; 'jus...@justinedelson.com'
Subject: RE: [DISCUSS] Correct listing of resource children (follow up
to SLING-1672)
I can confirm that case 1) does work.
If a ResourceProvider has a root of
/foo/bar, then it
shouldn't be expected to return
...@justinedelson.com'
Subject: RE: [DISCUSS] Correct listing of resource children (follow up
to SLING-1672)
I can confirm that case 1) does work.
If a ResourceProvider has a root of
/foo/bar, then it
shouldn't be expected to return resources for anything not
starting with /foo/bar.
agree
12 matches
Mail list logo
