Hi Andreas, 2018-07-06 20:59 GMT+00:00 Andreas Schaefer <schaef...@me.com.invalid>:
> > > 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. > > 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. * Good test coverage (the resource resolver grew into a complex beast over the years...) * I would prefer the "${placeholder}" format instead of "{{{placeholder}}}" format :-) -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
