[jira] [Commented] (SLING-4750) New Resource Provider API

["Robert Munteanu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108496#comment-15108496 ] 

Robert Munteanu commented on SLING-4750:
----------------------------------------

* [r1725715|https://svn.apache.org/r1725715] - added some toString() methods
* [r1725716|https://svn.apache.org/r1725716] - fixed spacing when dumping the ResourceProvider status

> New Resource Provider API
> -------------------------
>
>                 Key: SLING-4750
>                 URL: https://issues.apache.org/jira/browse/SLING-4750
>             Project: Sling
>          Issue Type: Improvement
>          Components: API, JCR, ResourceResolver
>            Reporter: Carsten Ziegeler
>            Assignee: Robert Munteanu
>              Labels: Sling-9-ReleaseNotes
>             Fix For: API 2.10.0, Resource Resolver 1.3.0
>
>
> Mail thread from the mailing list:
> http://mail-archives.apache.org/mod_mbox/sling-dev/201505.mbox/%3C555983ED.1080800%40apache.org%3E
> Starting mail:
> The resource provider API has grown a lot over time and when we started
> with it we didn't really think about potential extensions of the api.
> Today, each time we add a new feature, we come up with a new marker
> interface. There is also the distinction between a resource provider
> (singleton/stateless) and the factory (creating stateful providers).
> Although the api is not intended to be used by the average resource api
> user (it's an extension), we put it in the same package. And there are
> more minor things.
> Therefore I think it's time to start a new API that is more future proof
> and solves the known problems. I've created a draft prototype at [1].
> During the performance analysis by Joel he found out that getParent
> calls to a resource a pretty expensive as in the end these are string
> based. Therefore, e.g. the JCR implementation can't simply call
> getParent on a node and wrap it in a resource. Therefore I think we
> should add a getParent(Resource) method to the resource resolver and
> have a better way to handle this in a resource provider.
> Instead of having a resource provider and a resource provider factory,
> we define a single ResourceProvider which is a singleton. If this
> provider needs authentication and/or needs to keep state per user, the
> PROPERTY_AUTHENTICATE needs to be set to true and in this case the
> authenticate method is called. This one returns a data object which is
> passed in to each and every method. If auth is not required, the method
> is not called and null is passed in as the data object.
> For authentication, providers do not support login administrative
> anymore, just users and service users.
> A provider is mounted at a single root - no more support for mounting it
> at different path at the same time; and a provider always owns the root.
> So if a provider does not return a resource for a given path, no other
> provider is asked. This allows for improved implementations and resource
> resolving. If we decided that we need this for compatibility we can
> solve it differently.
> Instead of using marker interface, we define the ResourceProvider as an
> abstract class. This allows us to add new methods without breaking
> existing providers.
> Each method gets a ResolveContext, containing the resource resolver,
> the previously mentioned state data object and other things, e.g. the
> parameter support recently added to the resource resolving. In the
> future we can pass in additional data without breaking the interface.
> Apart from that the resource provider is similar to the aggregation of
> the already existing marker interfaces. There are two exceptions,
> observation and query which I'll handle in different emails.
> [1]
> https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api-v3/src/main/java/org/apache/sling/api/resource/provider/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)