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
