> On Jul 7, 2018, at 4:26 AM, Jörg Hoh <[email protected]> wrote:
>
> Hi Andreas,
>
> 2018-07-06 20:59 GMT+00:00 Andreas Schaefer <[email protected]>:
>
>>
>>
>> https://issues.apache.org/jira/browse/SLING-7768 <
>> https://issues.apache.org/jira/browse/SLING-7768>
>>
>
>
> In this ticket I see that you allow not only the replacement of property
> values, but also of resource names. Is that required? IIRC you can also
> work with "sling:match" properties, so the name of the resource is ignored.
> You haven't posted any implementation yet, so I wonder if that limitation
> could reduce the amount of changes to actually implement it.
I just posted a branch to the org-apache-sling-resourceresolver module called
feature/SLING-7768.
I think it would be best to support both ways (the node name as well as the
sling:match) to make it easier on the user.
Ruben and I think it could be helpful to make the Placeholder Provider more
generic to that it could be used in other services like the
distribution/replication, externalizers etc to have an easier way to manage
server configuration in a central place.
>
>
>>
>> The OSGi Web Plugin for the Resource Resolver actually shows the resolved
>> values making it easy to understand and check the /etc/map entries.
>>
>> For the Placeholder provider I also think it would be great if the
>> placeholder values could be provided from a URL (file or web page) and also
>> as CLI arguments:
>>
>> java -jar sling*.jar -Dphv.fq.host.name=my-host.com <http://my-host.com/>
>>
>> This would be helpful if a user messed up the /etc/map and cannot get back
>> into Sling.
>>
>
> Nice feature. My whishlist for it:
>
> * When I provide the placeholders via a file, this file should be monitored
> and reloaded as I change it. If I add more /etc/map entries during runtime
> and need to introduce new placeholders, I would like to update the
> placeholder file in parallel, and have the new entries effective without
> restarting.
> * No need to support anything else like files and system properties to
> provide the placeholders. Makes error handling much more complicated (what
> do you do if the http download of that placeholder file fails?), and I
> would rather leave it to the ops team to implement that process and handle
> any errors.
I see the issue with the external files / web resources. The system properties
are there to make sure an admin can override any settings if things do not work
out.
> * Good test coverage (the resource resolver grew into a complex beast over
> the years…)
Sure, will do.
> * I would prefer the "${placeholder}" format instead of "{{{placeholder}}}"
> format :-)
Do JCR node names support ${}? If so that can be easily changed.
>
>
> --
> Cheers,
> Jörg Hoh,
>
> http://cqdump.wordpress.com
> Twitter: @joerghoh
