Sling
  1. Sling
  2. SLING-1198

Allow mapping nodes to internet domains with template parameters

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: JCR Resource 2.0.2
    • Fix Version/s: None
    • Component/s: JCR
    • Labels:
      None

      Description

      Sling should support hosting multiple domains, with different JCR roots.
      E.g.:
      http://www.domain1.com could map to /content/domain1.com
      http://www.domain2.com could map to /content/domain2.com

      While developing a website, the fully qualified domain might not be available. Ideally, the mapping could be configured in a flexible way. One option would be to maintain a set of regular expressions to match against URLs. Each regexp would then match to a path in the JCR.

      1. MapEntry.patch
        8 kB
        Róbert Csákány
      2. MapEntry.pacth
        9 kB
        Róbert Csákány

        Issue Links

          Activity

          Hide
          Róbert Csákány added a comment -

          I've made a little modification in mapping.
          There are mapping parameter allowed (when you need dynamic virtual host to be mapped to pathes)
          This patch detects the URL is templated or not, if isn't templated the normal behaviour is used.

          Some information about the use of this patch:

          • it's designed for internal redirects - other cases not wasn't tested
          • I use with 1..1 mapping, so in Mappig there was only one internalredirect for the URL- other cases wasn't tested.

          The usage:

          If you define a @par(parname, regexp)@ in URL and the redirect URL, the resolver replace it to the given regexp, and when the URL matches replaces the parameter in the result.
          CAUTION! All parameter have to defined in URL and PATH too.

          Example:

          match: www\.@par(2,\w+)@\.@par(1,\w+)@\.domain\.com
          redirect: /home/@par(1,\w+)@/@par(2,\w+)@

          The resolve of: www.var1.var2.domain.com/testpage.html will returns /home/var2/var1/testpage.html
          The map of: /home/var1/var2/testpage.html returns www.var2.var1.domain.com/testpage.html

          Please review and test it, it works for me, but all comment and idea is help me to finish this patch.

          Show
          Róbert Csákány added a comment - I've made a little modification in mapping. There are mapping parameter allowed (when you need dynamic virtual host to be mapped to pathes) This patch detects the URL is templated or not, if isn't templated the normal behaviour is used. Some information about the use of this patch: it's designed for internal redirects - other cases not wasn't tested I use with 1..1 mapping, so in Mappig there was only one internalredirect for the URL- other cases wasn't tested. The usage: If you define a @par(parname, regexp)@ in URL and the redirect URL, the resolver replace it to the given regexp, and when the URL matches replaces the parameter in the result. CAUTION! All parameter have to defined in URL and PATH too. Example: match: www\.@par(2,\w+)@\.@par(1,\w+)@\.domain\.com redirect: /home/@par(1,\w+)@/@par(2,\w+)@ The resolve of: www.var1.var2.domain.com/testpage.html will returns /home/var2/var1/testpage.html The map of: /home/var1/var2/testpage.html returns www.var2.var1.domain.com/testpage.html Please review and test it, it works for me, but all comment and idea is help me to finish this patch.
          Hide
          Mike Müller added a comment -

          I haven't looked at the details of your patch and maybe I'm wrong. To me it seems to be a feature already existing: Have a look at the root level mappings under [1]. Aren't they solve the same issue?

          [1] http://sling.apache.org/site/mappings-for-resource-resolution.html

          Show
          Mike Müller added a comment - I haven't looked at the details of your patch and maybe I'm wrong. To me it seems to be a feature already existing: Have a look at the root level mappings under [1] . Aren't they solve the same issue? [1] http://sling.apache.org/site/mappings-for-resource-resolution.html
          Hide
          Róbert Csákány added a comment -

          No, I've tested. I need a functionality where the URL dynamic, and the redirect path also. In the original mapping the URL dynamic (matchin with regexp), but the redirect is static - so I have to create redirect mapping for all subdomain where the path mapping is different - you can redirect all of subdomains to one path in the original code. It's fact you can mapping the path in subdomains to other pathes, but it's static also - only matching code there, not replace. In my solution redirect all subdomains, but it's getting the subdomain and dynamically redirect to a path and vica versa.

          For example:

          Original code

          match: (\w+)\.\domain.com\.80
          redirectInternal: /home/domain1
          ----- cgi-bin -> /scripts
          ----- images -> /static/images

          when a request URL is;
          www.domain.com/cgi-bin -> it's redirected to /cgi-bin
          something.domain.com/ -> it's redirected to /home/domain1

          So the path is static.

          In my solution:

          match: @par(1,\w+)@.domain.com\.80
          redirectInternal: /home/domain1/@par(1,\w+)@

          when a request URL is;
          www.domain.com/cgi-bin -> it's redirected to /home/domain1/www
          something.domain.com/ -> it's redirected to /home/domain1/something

          I will chek my code again, because maybe the childs that no have parameter block (for example some static mapping under dynamic map) in the Mapping are not handled correctly (I check all of the mapping all parameter is presented or not, but I think this check is not neccessary in all cases).

          I hope I'm understandable.

          Show
          Róbert Csákány added a comment - No, I've tested. I need a functionality where the URL dynamic, and the redirect path also. In the original mapping the URL dynamic (matchin with regexp), but the redirect is static - so I have to create redirect mapping for all subdomain where the path mapping is different - you can redirect all of subdomains to one path in the original code. It's fact you can mapping the path in subdomains to other pathes, but it's static also - only matching code there, not replace. In my solution redirect all subdomains, but it's getting the subdomain and dynamically redirect to a path and vica versa. For example: Original code match: (\w+)\.\domain.com\.80 redirectInternal: /home/domain1 ----- cgi-bin -> /scripts ----- images -> /static/images when a request URL is; www.domain.com/cgi-bin -> it's redirected to /cgi-bin something.domain.com/ -> it's redirected to /home/domain1 So the path is static. In my solution: match: @par(1,\w+)@.domain.com\.80 redirectInternal: /home/domain1/@par(1,\w+)@ when a request URL is; www.domain.com/cgi-bin -> it's redirected to /home/domain1/www something.domain.com/ -> it's redirected to /home/domain1/something I will chek my code again, because maybe the childs that no have parameter block (for example some static mapping under dynamic map) in the Mapping are not handled correctly (I check all of the mapping all parameter is presented or not, but I think this check is not neccessary in all cases). I hope I'm understandable.
          Hide
          Jonathan 'J5' Cook added a comment -

          Robert is providing a good solution to a very real problem which relates to reversibility and substitution in the current ResourceResolver mappings.

          I am not familiar enough with how the current /etc/map based and "standard" (ResourceResolver2 and ResourceResolver style) rules are translated into MapEntry objects to know whether putting this patch in this class is appropriate or not, nor what the ramifications would be if it went forward.

          However, I find the functionality described and modeled by the patch to be very useful for my real-world applications in Day CQ 5.x

          Robert, thank you for putting the idea on the table and submitting a patch.

          I would call this "Reversible Reg-ex Based ResourceResolver Mappings Using Bi-Directional Pattern Parameterization". By making a portion of the regular expression both a pattern to match against and a target for replacements, a greater reversibility is possible.

          I would remove the requirement that all parameters always be present and allow for default values, and make sure that the mappings implementation only includes the FQDN and not just a relative request when the mapped URL FQDN does not match the request FQDN. I don't have time to evaluate the patch or modify it to do this. If the patch is acceptable as is, I could attempt to patch-the-patch to incorporate these additional ideas.

          +1 for the implementing the requested functionality as I understand it, with or without my ideas

          Show
          Jonathan 'J5' Cook added a comment - Robert is providing a good solution to a very real problem which relates to reversibility and substitution in the current ResourceResolver mappings. I am not familiar enough with how the current /etc/map based and "standard" (ResourceResolver2 and ResourceResolver style) rules are translated into MapEntry objects to know whether putting this patch in this class is appropriate or not, nor what the ramifications would be if it went forward. However, I find the functionality described and modeled by the patch to be very useful for my real-world applications in Day CQ 5.x Robert, thank you for putting the idea on the table and submitting a patch. I would call this "Reversible Reg-ex Based ResourceResolver Mappings Using Bi-Directional Pattern Parameterization". By making a portion of the regular expression both a pattern to match against and a target for replacements, a greater reversibility is possible. I would remove the requirement that all parameters always be present and allow for default values, and make sure that the mappings implementation only includes the FQDN and not just a relative request when the mapped URL FQDN does not match the request FQDN. I don't have time to evaluate the patch or modify it to do this. If the patch is acceptable as is, I could attempt to patch-the-patch to incorporate these additional ideas. +1 for the implementing the requested functionality as I understand it, with or without my ideas
          Hide
          Felix Meschberger added a comment -

          Thanks for providing the patch. Please give us some time to fully analyze the issue and proposed solution. Thanks.

          Show
          Felix Meschberger added a comment - Thanks for providing the patch. Please give us some time to fully analyze the issue and proposed solution. Thanks.
          Hide
          Róbert Csákány added a comment -

          Jonathan,

          I've implemented another patch where you can define @noparam@ in mappings - for example to use for shared contents by several domains, but there is a major conceptional issue. If you use parameters, you have to use all of them, or none of them, because the reversebility. In @noparam@ type mappings there are no reverse mapping - how can you determinate subdomain, if there will be severeal - thats the problem is presented also when you miss one or more parameters.

          I attach the modified patch - but as Felix described his DRAFT (http://cwiki.apache.org/confluence/display/SLING/Resource+Resolution+Plugins), I will investigate to make my path "pluggable", because I have another type of mapping requirements in my projects.

          Show
          Róbert Csákány added a comment - Jonathan, I've implemented another patch where you can define @noparam@ in mappings - for example to use for shared contents by several domains, but there is a major conceptional issue. If you use parameters, you have to use all of them, or none of them, because the reversebility. In @noparam@ type mappings there are no reverse mapping - how can you determinate subdomain, if there will be severeal - thats the problem is presented also when you miss one or more parameters. I attach the modified patch - but as Felix described his DRAFT ( http://cwiki.apache.org/confluence/display/SLING/Resource+Resolution+Plugins ), I will investigate to make my path "pluggable", because I have another type of mapping requirements in my projects.
          Hide
          Felix Meschberger added a comment -

          > I will investigate to make my path "pluggable"

          That makes sense. I am in the process of prototyping this concept... But there is nothing yet to share.

          Show
          Felix Meschberger added a comment - > I will investigate to make my path "pluggable" That makes sense. I am in the process of prototyping this concept... But there is nothing yet to share.
          Hide
          Róbert Csákány added a comment -

          Here is the modified patch I mentioned before. There is a new feature, @noparam@ in Map entries to be able to resolve shared node entries. Here is an (real life) example:

          /etc/map/http/domain1.com
          — jcr:primaryType=sling:Mapping
          sling:internalRedirect=/users/@par(1,\w+)@
          sling:match=@par(1,\w+)@\.domain1\.com.8080

          /etc/map/http/domain1.com/images
          — sling:internalRedirect=@noparam@/content/shared/images/

          /etc/map/http/domain1.com/css
          — sling:internalRedirect=@noparam@/content/shared/css/

          cases:

          Resolver:
          1. http://test1.domain1.com/index.html -> /users/test1.domain1.com/index.html
          2. http://test2.domain1.com/images/glass.jpg -> /content/shared/images/glass.jpg

          Map:
          1. /users/test1.domain1.com/index.html -> http://test1.domain1.com/index.html
          2. /content/shared/images/glass.jpg -> /content/shared/images/glass.jpg

          That's all folks

          Show
          Róbert Csákány added a comment - Here is the modified patch I mentioned before. There is a new feature, @noparam@ in Map entries to be able to resolve shared node entries. Here is an (real life) example: /etc/map/http/domain1.com — jcr:primaryType=sling:Mapping sling:internalRedirect=/users/@par(1,\w+)@ sling:match=@par(1,\w+)@\.domain1\.com.8080 /etc/map/http/domain1.com/images — sling:internalRedirect=@noparam@/content/shared/images/ /etc/map/http/domain1.com/css — sling:internalRedirect=@noparam@/content/shared/css/ cases: Resolver: 1. http://test1.domain1.com/index.html -> /users/test1.domain1.com/index.html 2. http://test2.domain1.com/images/glass.jpg -> /content/shared/images/glass.jpg Map: 1. /users/test1.domain1.com/index.html -> http://test1.domain1.com/index.html 2. /content/shared/images/glass.jpg -> /content/shared/images/glass.jpg That's all folks
          Hide
          Carsten Ziegeler added a comment -

          Change fix for version to 2.0.8 as 2.0.4 is already released

          Show
          Carsten Ziegeler added a comment - Change fix for version to 2.0.8 as 2.0.4 is already released
          Hide
          Alexander Klimetschek added a comment -

          The syntax looks crazy and the "mandatory" @noparam@ is not a good idea.

          Shouldn't those complex rewrite rules be done with mod_rewrite in an apache server in front? Doesn't support reverse mapping of course.

          Or support such extensions via a custom mapping provider / plugin...

          Just my 2 cents.

          Show
          Alexander Klimetschek added a comment - The syntax looks crazy and the "mandatory" @noparam@ is not a good idea. Shouldn't those complex rewrite rules be done with mod_rewrite in an apache server in front? Doesn't support reverse mapping of course. Or support such extensions via a custom mapping provider / plugin... Just my 2 cents.
          Hide
          Justin Edelson added a comment -

          descheduling from current release

          Show
          Justin Edelson added a comment - descheduling from current release
          Hide
          Róbert Csákány added a comment -

          Alexander:
          I think it's better to use internal solution like mod_rewrite -> if I follow this logic all the mappings can be done with mod_rewrite, but what about if somebody wanna use jk_mod?
          The @noparam@ entry have to be used if @par@ parameter presented in the parent sling:Mapping node, so if you are not using the @par@, the @noparam@ is not handled.

          The plugin system is a good idea, but (as I know) there is no plugin system developed yet for mapping. Felix made a draft proposal, but it isn't developed yet.

          Show
          Róbert Csákány added a comment - Alexander: I think it's better to use internal solution like mod_rewrite -> if I follow this logic all the mappings can be done with mod_rewrite, but what about if somebody wanna use jk_mod? The @noparam@ entry have to be used if @par@ parameter presented in the parent sling:Mapping node, so if you are not using the @par@, the @noparam@ is not handled. The plugin system is a good idea, but (as I know) there is no plugin system developed yet for mapping. Felix made a draft proposal, but it isn't developed yet.

            People

            • Assignee:
              Felix Meschberger
              Reporter:
              Róbert Csákány
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development