[
https://issues.apache.org/jira/browse/SLING-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904986#action_12904986
]
Felix Meschberger commented on SLING-1675:
------------------------------------------
With the changes of SLING-1672 together with the previous refactoring of
resource provider maintenance the situation has changed.
Now the BundleResourceProvider is registered at the /foo/bar node in the
resource provider tree. When listing the children of /foo, the resolver asks
the BundleResourceProvider (getResource-style) for the resource /foo/bar. If
the provider has the resource it is returned as part of the child resource
iterator for /foo. Otherwise a synthetic resource /foo/bar is returned.
Only when asking for the children of /foo/bar will the BundleResourceProvider
actually be asked for the children by calling the ResourceProvider.listChildren
method.
> BundleResourceProvider doesn't provide resources when asked to list the
> children of a mapped path
> -------------------------------------------------------------------------------------------------
>
> Key: SLING-1675
> URL: https://issues.apache.org/jira/browse/SLING-1675
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Reporter: Justin Edelson
>
> If you have
> <Sling-Bundle-Resources>/foo/bar</Sling-Bundle-Resources>
> and the resource at "/foo" exists (say, provided by the JCR Resource
> Provider), then a call to BundleResourceProvider.listChildren(resource) where
> the resource is an existing resource at "/foo", then BRP should return an
> iterator over the root bundle resource (i.e. /foo/bar in this case).
> This is similar to SLING-1672 with the difference being that /foo/bar is a
> legitimate bundle resource, whereas SLING-1672 is about having BRP provide a
> resource in listChildren() which it will not in getResource().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
