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. 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). 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
