Again my answers are inline. > On 19 Apr 2016, at 16:42, Julian Sedding <jsedd...@gmail.com> wrote: > > Hi Konrad > > See my reply inline. > > Regards > Julian > > On Tue, Apr 19, 2016 at 3:32 PM, Konrad Windszus <konra...@gmx.de> 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?
That sounds like a reasonable proposal. I created the issue https://issues.apache.org/jira/browse/SLING-5672 for that. I had a look in the code though, and in the current state I don't dare to commit anything within mapping classes. The logic is so complex and convoluted and the namings are confusing which are being used there. Therefore someone else would need to take that up. > >> Thanks, >> Konrad >> >> >>> On 19 Apr 2016, at 15:12, Julian Sedding <jsedd...@gmail.com> 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 <konra...@gmx.de> 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 >>
