And all of the SLING-1672-related changes should only impact listChildren(), not individual resource resolution. So the use of the file system provider to shadow resources from JCR should remain unchanged.
Justin On Sep 6, 2010, at 6:29 PM, Eric Norman <eric.d.nor...@gmail.com> wrote: > Hi Vidar, > > My proposed patch affects only the BundleResourceProvider so I don't think > it would affect the scenario you have described. > > Regards, > Eric > > On Mon, Sep 6, 2010 at 1:30 PM, Vidar Ramdal <vi...@idium.no> wrote: > >>> On 06.09.2010 19:48, Eric Norman wrote: >>>> Hi All, >>>> >>>> This seems kind of similar to* >>>> SLING-1672<https://issues.apache.org/jira/browse/SLING-1672> >>>> * which has been marked as resolved. However, with the latest trunk >> code, I >>>> am still running into some difficulties when multiple bundles are >> providing >>>> Sling-Bundle-Resources with the same path. I would assume that the >> children >>>> of all the providers at the same path should be merged together? >> Currently, >>>> it seems that the first parent resource found wins, and listing the >> children >>>> only return the scripts in that bundle. The scripts provided by the >> other >>>> bundles are not visible. Obviously, this makes it difficult to have >> modular >>>> bundles if all the scripts need to be inside the same bundle to be >> found. >>>> . >>>> For example: >>>> >>>> Bundle 1 contains these scripts: >>>> /libs/sling/servlet/default/script1.html.esp >>>> /libs/sling/servlet/default/script2.html.esp >>>> >>>> And the resource is provided as: >>>> <Sling-Bundle-Resources> >>>> /libs/sling/servlet/default >>>> </Sling-Bundle-Resources> >>>> >>>> Bundle 2 contains these scripts: >>>> /libs/sling/servlet/default/script2.html.esp >>>> /libs/sling/servlet/default/script3.html.esp >>>> >>>> And the resource is provided as: >>>> <Sling-Bundle-Resources> >>>> /libs/sling/servlet/default >>>> </Sling-Bundle-Resources> >>>> >>>> >>>> With both bundles installed, you either see the scripts from bundle1 or >> the >>>> scripts from bundle2 but not both. >>>> >>>> Thoughts? >> >> On Mon, Sep 6, 2010 at 8:56 PM, Felix Meschberger <fmesc...@gmail.com> >> wrote: >>> I would say, your use case is perfectly valid and really should work. >>> >>> If not, we would have to analyze where in the listChildren >>> implementation the problem lies. >>> >>> At least we would have to have an issue to track this. >> >> If a (hypothetic) patch should apply to all kinds of resource >> providers (not just bundle resource providers, as in the example >> above) it would probably break a very common use case: >> Bundles that provides initial content. During development, it is >> useful to map the resource paths to disk directories, using >> FsResourceProviders. This currently works, because FsResourceProvider >> overrides the JCR content paths. >> Example: >> - Bundle A provides /apps/something/scripts as initial content. During >> development, /apps/something/scripts is mapped to >> /Users/somebody/something/scripts, for a short round-trip development >> cycle. >> If the above suggestion is implemented, the resource path >> /apps/something/scripts would list content from both JCR and disk. >> >> -- >> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no >> Sommerrogata 13-15, N-0255 Oslo, Norway >> + 47 22 00 84 00 / +47 22 00 84 76 >> Quando omni flunkus moritatus! >>
