[
https://issues.apache.org/jira/browse/SLING-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14803139#comment-14803139
]
Tomek Rękawek edited comment on SLING-4750 at 9/22/15 2:51 PM:
---------------------------------------------------------------
I'm working on this here: https://github.com/trekawek/sling/tree/SLING-4750
Current status:
* org.apache.sling.jcr.resource rewritten to use new API,
* org.apache.slign.resourceresolver is based on the new API,
* there is a bridge service for the legacy providers,
* Sling launchpad starts succesfully and shows the main page :)
TODO:
* (/) run integration tests,
* add comments,
* add unit tests.
was (Author: tomek.rekawek):
I'm working on this here: https://github.com/trekawek/sling/tree/SLING-4750
Current status:
* org.apache.sling.jcr.resource rewritten to use new API,
* org.apache.slign.resourceresolver is based on the new API,
* there is a bridge service for the legacy providers,
* Sling launchpad starts succesfully and shows the main page :)
TODO:
* run integration tests,
* add comments,
* add unit tests.
> 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: Tomek Rękawek
> Fix For: API 2.10.0, Resource Resolver 1.2.8
>
>
> 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)
