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