On Tue, Sep 7, 2010 at 12:51 AM, Justin Edelson <justinedel...@gmail.com> wrote: > 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.
Ah, good :) > > 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! >>> > -- 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!
