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 2018/03/07 16:12:45 UTC

[RT] Improvement for getting the resolver search paths

Hi,

right now, the only possible way to get the configured search paths for
resource resolving is to actually create a resource resolver (by logging
in using a service user). Then the search paths array can be get from
the resolver and the resolver can be closed.
This is pretty expensive for just getting a setting.

In theory, each resolver could have different search paths; in reality
we never went down this road and I think in fact we can't. There is a
lot of code out there, assuming that each resolver has the same search
paths; the resource change listener act in exactly the same way.

Therefore I suggest we simply add the search paths as a service
registration property of the resource resolver factory. This makes
getting this setting very easy without even getting a service.

WDYT?

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [RT] Improvement for getting the resolver search paths

Posted by Radu Cotescu <ra...@apache.org>.
+1. I've always found it awkward that I have to get a resolver to retrieve
the search paths, when you configure them on the RRFActivator.

On Wed, 7 Mar 2018 at 17:12 Carsten Ziegeler <cz...@apache.org> wrote:

> Hi,
>
> right now, the only possible way to get the configured search paths for
> resource resolving is to actually create a resource resolver (by logging
> in using a service user). Then the search paths array can be get from
> the resolver and the resolver can be closed.
> This is pretty expensive for just getting a setting.
>
> In theory, each resolver could have different search paths; in reality
> we never went down this road and I think in fact we can't. There is a
> lot of code out there, assuming that each resolver has the same search
> paths; the resource change listener act in exactly the same way.
>
> Therefore I suggest we simply add the search paths as a service
> registration property of the resource resolver factory. This makes
> getting this setting very easy without even getting a service.
>
> WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>

Re: [RT] Improvement for getting the resolver search paths

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 8, 2018 at 4:52 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> The property can be set using the existing configuration (as we have the
> config before we register the service). But I decided now to simply add
> a message to the ResourceResolverFactory...

Thanks, yes adding a method makes sense.

-Bertrand

Re: [RT] Improvement for getting the resolver search paths

Posted by Carsten Ziegeler <cz...@apache.org>.
The property can be set using the existing configuration (as we have the
config before we register the service). But I decided now to simply add
a message to the ResourceResolverFactory as this avoids a contract to
the service registry and we stay in OSGi-less service API :)

Regards

Carsten


Bertrand Delacretaz wrote
> Hi Carsten,
> 
> On Wed, Mar 7, 2018 at 5:12 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...I suggest we simply add the search paths as a service
>> registration property of the resource resolver factory. This makes
>> getting this setting very easy without even getting a service...
> 
> Sounds good but isn't there a potential backwards compatibility issue?
> Or would you just set that property from the existing config?
> 
> -Bertrand
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: [RT] Improvement for getting the resolver search paths

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Carsten,

On Wed, Mar 7, 2018 at 5:12 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I suggest we simply add the search paths as a service
> registration property of the resource resolver factory. This makes
> getting this setting very easy without even getting a service...

Sounds good but isn't there a potential backwards compatibility issue?
Or would you just set that property from the existing config?

-Bertrand