Hi Konrad See my reply inline.
Regards Julian On Tue, Apr 19, 2016 at 3:32 PM, Konrad Windszus <[email protected]> wrote: > Hi Julian, > thanks for that hint. I will try it out. > Still it is not possible with b) to have the same mapping rule being applied > to all hosts/schemes/ports without maintaining it separately for each > host/scheme/port. Absolutely, and that can be painful, especially if you only have a single vhost, but different environments (e.g. dev, test, stage, prod). I work around this by configuring the location of /etc/maps depending on the runmode. Still it requires me to maintain mappings for different environments. > I very often use the vhost section in the web server in front to do the > mapping from one vhost to a certain root path within the repo, e.g. > /content/customer/website. Therefore within Sling I am mostly interested in > stripping the first three levels for all paths starting with /content in the > outward mapping. I currently do not see how to easily accomplish that with b). I don't see how this can be done with a catch-all rule either. The config would need to be duplicated for each vhost. Maybe we should start supporting a wildcard/regexp for the hostname? If it is e.g. "*", the rule applies to any value unless a more specific rule is found. WDYT? > Thanks, > Konrad > > >> On 19 Apr 2016, at 15:12, Julian Sedding <[email protected]> wrote: >> >> Hi Konrad >> >> In my opinion b) is the preferred way, even though it is slightly more >> complicated to configure. >> >> Use-case 1) is possible with b), but not very well documented. >> Essentially, you can provide a regexp as the value of >> sling:internalRedirect (and replacements in sling:match), in which >> case the mapping is only used for the outward mapping (i.e. RR.map()). >> See SLING-2560 for details. >> >> If a) is not already deprecated, maybe we should deprecate it? The >> whole mapping business is overly complicated IMHO and any reduction of >> the complexity is welcome. >> >> Regards >> Julian >> >> On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus <[email protected]> wrote: >>> Currently there are two possibilities to configure the resource resolver >>> mapping: >>> >>> a) Through the OSGi property "resource.resolver.mapping" of the PID >>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl >>> b) Through the resources below the path being specified by the OSGI >>> property "resource.resolver.map.location" of the PID >>> org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl >>> >>> Both possibilities are overlapping in certain parts, but some aspects can >>> only be configured in either a) or b). Let me quickly reconsider which way >>> supports which features >>> >>> 1) Different incoming and outgoing mappings can only be given in a) because >>> b) will always assume the mapping is for both directions (except in the >>> case when regular expression are used, as then the entry in b) will only be >>> used for incoming mapping. To only specify an outgoing mapping with b) is >>> impossible) >>> 2) Mapping for a specific Host or Scheme can only be given in b). I opened >>> https://issues.apache.org/jira/browse/SLING-5670 about that! >>> 3) Redirecting for incoming mappings is only supported through b) >>> 3) Reconfiguring through a) is more expensive as this requires a lot of >>> depending OSGi services to be restarted! >>> >>> I have the feeling, that b) is the preferred way from a performance but >>> also from a feature point of view, but it is very sad that b) is lacking >>> the possibility 1. >>> >>> So instead of extending both mechanisms to make them cover the same >>> features, I would like to know what is the recommended approach. >>> >>> Then we can look into how to make the full feature set maintainable through >>> this preferred way of configuring and at the same time deprecate the other. >>> >>> Thanks, >>> Konrad >
