You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2015/05/18 08:17:17 UTC
[RT] New Resource Provider API
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/
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [RT] New Resource Provider API
Posted by Stefan Seifert <ss...@pro-vision.de>.
>> We could provide a way through the ResolveContext to get the "parent"
>> provider and check that one for a resource.
>
>I think that should work for these cases, yes. This would make any
>cascading the responsibility of the ResourceProvider implementation,
>similar to how servlet filters work.
+1
with the current resourceprovider concept such a "request the parent resource resolver" was missing, because of this the superimposing resource provider had to fall back to the JCR API for this making it JCR-dependent.
>I have some concerns about the provider always owning the root,
>however. I understand that this makes it easier to have good
>performance by default.
as long as it is cheap to have multiple (perhaps lots) of resource provider instances this should not be problem. with the superimposing content provider e.g. it may be required to have thousands of instances each assigned to one specific root.
stefan
Re: [RT] New Resource Provider API
Posted by Julian Sedding <js...@gmail.com>.
> We could provide a way through the ResolveContext to get the "parent"
> provider and check that one for a resource.
I think that should work for these cases, yes. This would make any
cascading the responsibility of the ResourceProvider implementation,
similar to how servlet filters work.
Regards
Julian
On Mon, May 18, 2015 at 4:27 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Am 18.05.15 um 16:11 schrieb Julian Sedding:
>> Hi Carsten
>>
>> Overall I welcome a cleanup in this area, so +1.
>>
>> I have some concerns about the provider always owning the root,
>> however. I understand that this makes it easier to have good
>> performance by default. But I also believe that there are use-cases
>> where it is desirable to enhance a resource tree that is predominantly
>> provided by another provider. E.g. add a child resource called
>> "accessStats" blow every resource of type "page", or the
>> {{SuperimposingResourceProvider}}.
>>
>> How could these scenarios be implemented? Maybe they could proxy all
>> calls, but this would require that they can easily query "all
>> providers except themselves". But then all calls would be proxied,
>> potentially leading to multiple layers of delegation.
>>
>> Maybe someone else has a better idea?!
>>
> Of course we can keep the current flexibility to select whether the
> provider owns the root.
> However I would prefer to not have this flexibility anymore.
> We could provide a way through the ResolveContext to get the "parent"
> provider and check that one for a resource.
>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 18.05.15 um 16:11 schrieb Julian Sedding:
> Hi Carsten
>
> Overall I welcome a cleanup in this area, so +1.
>
> I have some concerns about the provider always owning the root,
> however. I understand that this makes it easier to have good
> performance by default. But I also believe that there are use-cases
> where it is desirable to enhance a resource tree that is predominantly
> provided by another provider. E.g. add a child resource called
> "accessStats" blow every resource of type "page", or the
> {{SuperimposingResourceProvider}}.
>
> How could these scenarios be implemented? Maybe they could proxy all
> calls, but this would require that they can easily query "all
> providers except themselves". But then all calls would be proxied,
> potentially leading to multiple layers of delegation.
>
> Maybe someone else has a better idea?!
>
Of course we can keep the current flexibility to select whether the
provider owns the root.
However I would prefer to not have this flexibility anymore.
We could provide a way through the ResolveContext to get the "parent"
provider and check that one for a resource.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Julian Sedding <js...@gmail.com>.
Hi Carsten
Overall I welcome a cleanup in this area, so +1.
I have some concerns about the provider always owning the root,
however. I understand that this makes it easier to have good
performance by default. But I also believe that there are use-cases
where it is desirable to enhance a resource tree that is predominantly
provided by another provider. E.g. add a child resource called
"accessStats" blow every resource of type "page", or the
{{SuperimposingResourceProvider}}.
How could these scenarios be implemented? Maybe they could proxy all
calls, but this would require that they can easily query "all
providers except themselves". But then all calls would be proxied,
potentially leading to multiple layers of delegation.
Maybe someone else has a better idea?!
Regards
Julian
On Mon, May 18, 2015 at 8:17 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> 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/
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 21.05.15 um 12:34 schrieb Stefan Seifert:
>
> hmm, did not see them in the existing interface?
> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceProvider.java
>
It's
https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/AttributableResourceProvider.java
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [RT] New Resource Provider API
Posted by Stefan Seifert <ss...@pro-vision.de>.
>Ok, this would mean the following I think:
>1. move/copy on the resource resolver
>2. optional move/copy on a provider
>3. if the resource resolver impl detects that a move is within a
>provider, it calls the move/copy on the provider
>4. if the move/copy is across providers, the resource resolver impl does
>this brute force.
perfect!
>> 4. is it good to have only an abstract class? this makes mocking more
>difficult. I would prefer to have an interface plus an abstract class.
>> if one decides not to use the abstract class he has the risk to get
>problems on additions, but the interface is clean.
>
>Having both will lead to the problem that once we add stuff to the
>interface, a provider might not work (resolve) anymore. You'll find the
>approach with the abstract class in some OSGi specs and it seems to work
>pretty well.
>I'm not an expert, but I think mocking of abstract classes is not a problem.
yes, seems so: http://stackoverflow.com/a/4317631 - ok
>> 5. for what are the getAttribute/getAttributeNames properties? do they
>return OSGi properties? makes this sense? or what else is returned for what
>purpose?
>This is already part of the current provider interface. Providers can
>provide attributes which are available through the respective resource
>resolver calls.
hmm, did not see them in the existing interface?
https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/ResourceProvider.java
stefan
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Stefan,
thanks for the feedback, more inline...
>
> ResourceProvider.java
> ---------------------
>
> 1. we should rename the package to something like o.a.sling.spi.resource.provider to distinguish clearly from the API itself
> (same may apply to other classes not related to the resource provider, e.g. ResourceDecorator)
Sounds fine to me.
>
> 2. property provider.required: does this replace the property for required resource providers in ResourceResolverFactoryActivator? what happens if the required resource provider is not deployed/started at all, in this case the resource resolver starts anyway?
No, this does not replace it - the current ResourceProvider interface
has the same property. If this flag is set to true and the provider is
available, authenticate will be called on the provider, and only if this
succeeds for all marked providers, the login is considered successful.
If it fails on one of them, the login is failed.
(The prop on ResourceResolverFactoryActivator means that these providers
need to be registered in order to have resource resolver).
>
> 3. maybe we should add methods for copy/move resources as well? the underlying respositories have good support for it (JCR, oak).
> I just stumbled on some code lines in org.apache.sling.discovery.impl which only falls back to the JCR API to move a resource and
> otherwise would be independent of JCR. this has to be added in the
ResourceResolver API as well then. this could be optional so that
> not all resource providers have to implement it.
Ok, this would mean the following I think:
1. move/copy on the resource resolver
2. optional move/copy on a provider
3. if the resource resolver impl detects that a move is within a
provider, it calls the move/copy on the provider
4. if the move/copy is across providers, the resource resolver impl does
this brute force.
>
> 4. is it good to have only an abstract class? this makes mocking more difficult. I would prefer to have an interface plus an abstract class.
> if one decides not to use the abstract class he has the risk to get
problems on additions, but the interface is clean.
Having both will lead to the problem that once we add stuff to the
interface, a provider might not work (resolve) anymore. You'll find the
approach with the abstract class in some OSGi specs and it seems to work
pretty well.
I'm not an expert, but I think mocking of abstract classes is not a problem.
>
> 5. for what are the getAttribute/getAttributeNames properties? do they return OSGi properties? makes this sense? or what else is returned for what purpose?
This is already part of the current provider interface. Providers can
provide attributes which are available through the respective resource
resolver calls.
>
> 6. for what use is the adaptTo method with the special signature including the ResolveContext? who should adapt ResourceProvider SPI instances?
The resource resolver impl will call this, when adaptTo is called on the
resource resolver. So, e.g. the jcr provider can implement
adaptTo(Session.class) through this.
>
>
> ResolveContext.java
> -------------------
>
> 7. add support for a "getParentResourceResolver" for providers that overlay other ones like superimposing content provider, as discussed in the list
Yepp.
>
> 8. for what is the <T> used which is returned as getProviderState?
That's the object returned by the authenticate method on the provider.
>
> 9. getParameters() - shouldn't this be a <String,Object> map like most maps in sling?
Maybe this is badly named :) This is the parameter support for resolving
resources which has been added some months ago. And that map is a string
to string map.
Regards
Carsten
>
>
> stefan
>
>
>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: Monday, May 18, 2015 8:17 AM
>> To: Sling Developers
>> Subject: [RT] New Resource Provider API
>>
>> 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/
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [RT] New Resource Provider API
Posted by Stefan Seifert <ss...@pro-vision.de>.
hello carsten.
first feedback from my side:
ResourceProvider.java
---------------------
1. we should rename the package to something like o.a.sling.spi.resource.provider to distinguish clearly from the API itself
(same may apply to other classes not related to the resource provider, e.g. ResourceDecorator)
2. property provider.required: does this replace the property for required resource providers in ResourceResolverFactoryActivator? what happens if the required resource provider is not deployed/started at all, in this case the resource resolver starts anyway?
3. maybe we should add methods for copy/move resources as well? the underlying respositories have good support for it (JCR, oak). I just stumbled on some code lines in org.apache.sling.discovery.impl which only falls back to the JCR API to move a resource and otherwise would be independent of JCR. this has to be added in the ResourceResolver API as well then. this could be optional so that not all resource providers have to implement it.
4. is it good to have only an abstract class? this makes mocking more difficult. I would prefer to have an interface plus an abstract class. if one decides not to use the abstract class he has the risk to get problems on additions, but the interface is clean.
5. for what are the getAttribute/getAttributeNames properties? do they return OSGi properties? makes this sense? or what else is returned for what purpose?
6. for what use is the adaptTo method with the special signature including the ResolveContext? who should adapt ResourceProvider SPI instances?
ResolveContext.java
-------------------
7. add support for a "getParentResourceResolver" for providers that overlay other ones like superimposing content provider, as discussed in the list
8. for what is the <T> used which is returned as getProviderState?
9. getParameters() - shouldn't this be a <String,Object> map like most maps in sling?
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Monday, May 18, 2015 8:17 AM
>To: Sling Developers
>Subject: [RT] New Resource Provider API
>
>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/
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
I've updated the API based on the feedback so far (I'll incorporate the
latest from Georg soon).
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 26.05.15 um 21:59 schrieb Stefan Seifert:
>
>> Am 22.05.15 um 14:51 schrieb Stefan Seifert:
>>> this is another idea from Santiago García Pimentel an API extension that
>> affects both ResourceProvider SPI and the Resource/ResourceResolver API.
>>>
>>> Provide a mechanism to order resources
>>> https://issues.apache.org/jira/browse/SLING-4741
>>>
>>> some resource provider like JCR/oak can support this, others may not (e.g.
>> the nosql resource provider currently always returns the resources sorted
>> alphabetically to avoid storage of complex ordering info).
>>>
>> Right, good idea - I would leave it out for the moment. But for the next
>> API we should definitely consider this.
>
> Sling API v4...?
> at least when working with JCR this is not an uncommon usecase.
> this would affect several methods - create, copy, move etc.
>
:) I'm not against adding this to v3 (that's what I meant with the
unclear sentence above). I just thought that we do it step by step. If
someone has a proposal on how to do it, feel free to add it to the
current draft
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [RT] New Resource Provider API
Posted by Stefan Seifert <ss...@pro-vision.de>.
>Am 22.05.15 um 14:51 schrieb Stefan Seifert:
>> this is another idea from Santiago García Pimentel an API extension that
>affects both ResourceProvider SPI and the Resource/ResourceResolver API.
>>
>> Provide a mechanism to order resources
>> https://issues.apache.org/jira/browse/SLING-4741
>>
>> some resource provider like JCR/oak can support this, others may not (e.g.
>the nosql resource provider currently always returns the resources sorted
>alphabetically to avoid storage of complex ordering info).
>>
>Right, good idea - I would leave it out for the moment. But for the next
>API we should definitely consider this.
Sling API v4...?
at least when working with JCR this is not an uncommon usecase.
this would affect several methods - create, copy, move etc.
stefan
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 22.05.15 um 14:51 schrieb Stefan Seifert:
> this is another idea from Santiago García Pimentel an API extension that affects both ResourceProvider SPI and the Resource/ResourceResolver API.
>
> Provide a mechanism to order resources
> https://issues.apache.org/jira/browse/SLING-4741
>
> some resource provider like JCR/oak can support this, others may not (e.g. the nosql resource provider currently always returns the resources sorted alphabetically to avoid storage of complex ordering info).
>
Right, good idea - I would leave it out for the moment. But for the next
API we should definitely consider this.
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: [RT] New Resource Provider API
Posted by Stefan Seifert <ss...@pro-vision.de>.
this is another idea from Santiago García Pimentel an API extension that affects both ResourceProvider SPI and the Resource/ResourceResolver API.
Provide a mechanism to order resources
https://issues.apache.org/jira/browse/SLING-4741
some resource provider like JCR/oak can support this, others may not (e.g. the nosql resource provider currently always returns the resources sorted alphabetically to avoid storage of complex ordering info).
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Monday, May 18, 2015 8:17 AM
>To: Sling Developers
>Subject: [RT] New Resource Provider API
>
>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/
>
>Regards
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, May 26, 2015 at 9:02 AM, Georg Henzler <sl...@ghenzler.de> wrote:
> ...I
> remember a POC I did two years ago that had to evaluate how the system deals
> with 20k+ resource providers...
Interesting - this and other discussions in this thread make me think
that before redesigning such a key API we should have a list of use
cases and constraints. I don't think an email discussion is
sufficient.
-Bertrand
Re: [RT] New Resource Provider API
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Georg,
Am 26.05.15 um 09:02 schrieb Georg Henzler:
>
> Depending on the use case, you can end up with *many* resource providers
> - I remember a POC I did two years ago that had to evaluate how the
> system deals with 20k+ resource providers. Result back then: Overall
> system performance ok, but the the services tab in the OSGi Felix
> console completely overloads the browser with too many json records when
> clicking the "services" tab (making that tab unusable). What about
> making PROPERTY_ROOT optional? If not set on the service one resource
> provider instance could provide resources for the whole tree (having the
> framework asking it for any resource requested), if the property is set
> the behaviour could be as described. This obviously means such a "global
> provider" needs to be implemented with great care (performance!), but
> for some use cases it would definitely be cleaner to have this
> implementation option.
Ok, so you were not hitting a limit in the framework or the resource
resolution, but in a management console :)
The problem I want to solve is to have the most efficient resolution and
solve some of the problems we have today: a query might return resources
that are not gettable through the resource tree and things like that.
So instead of complicating our part, let's solve the web console :)
>
>>> public abstract @CheckForNull Resource getResource(final @Nonnull
>>> ResolveContext<T> ctx, final @Nonnull String path);
>
> The central function that has to be implemented takes a string path as
> argument (in both the old and the new interface). From my feeling it
> could be better to use a combination of parent (Resource) and name
> (String). This would be in line with listChildren() and makes it easier
> to embed resources in an existing tree.
Ups, thanks for pointing this out, I actually wanted to do something
like this. Will have a look
Regards
Carsten
>
> Regards
> Georg
>
>
> On 2015-05-18 08:17, Carsten Ziegeler wrote:
>> 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.
>>
>
>>
>> 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/
>>
>>
>> Regards
>> Carsten
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] New Resource Provider API
Posted by Georg Henzler <sl...@ghenzler.de>.
Hi Carsten,
here are my 2 cents:
> 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.
Depending on the use case, you can end up with *many* resource providers
- I remember a POC I did two years ago that had to evaluate how the
system deals with 20k+ resource providers. Result back then: Overall
system performance ok, but the the services tab in the OSGi Felix
console completely overloads the browser with too many json records when
clicking the "services" tab (making that tab unusable). What about
making PROPERTY_ROOT optional? If not set on the service one resource
provider instance could provide resources for the whole tree (having the
framework asking it for any resource requested), if the property is set
the behaviour could be as described. This obviously means such a "global
provider" needs to be implemented with great care (performance!), but
for some use cases it would definitely be cleaner to have this
implementation option.
>> public abstract @CheckForNull Resource getResource(final @Nonnull
>> ResolveContext<T> ctx, final @Nonnull String path);
The central function that has to be implemented takes a string path as
argument (in both the old and the new interface). From my feeling it
could be better to use a combination of parent (Resource) and name
(String). This would be in line with listChildren() and makes it easier
to embed resources in an existing tree.
Regards
Georg
On 2015-05-18 08:17, Carsten Ziegeler wrote:
> 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.
>
>
> 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/
>
> Regards
> Carsten