Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Implement beta site with CQ 5.6 resource resolver

vsharm3
Level 2
Level 2

Team,

    We are working on setting up a beta site with the same domain as main site, but support using the same author instance. We are thinking that on author, we would have two content nodes - /content/mainsite/en/mainsitepages for main site and /content/betasite/en/betasitepages

Author should be able to publish pages from both these places. No issues so far.

 

However, on publish instance, if we are hitting the publisher specified for beta site traffic then it should first look at the contents in main site path /content/mainsite/en/mainsitepages and it does not find  (404) then look at the beta site path - /content/betasite/en/betasitepages

On the other publish instance which is assigned to serve the main site traffic, it should always look at the main site path /content/mainsite/en/mainsitepages and if it does not find the page then throw 404 error.

I think this can be implemented using resource resolver but I am not quite sure how should move forward.

I have been looking at the resource resolver documentation - http://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html and was looking at internal redirect but could not find any other useful information.

I am not sure at this point if I am at the right track.  Has anyone implemented similar support for beta site? Any suggestion or tips will be helpful. Thanks.

1 Accepted Solution
Paul_McMahon
Correct answer by
Level 8
Level 8

In order to do this with the out of the box resource resolver you need the following conditions:

  1. You would need to be passing back short URLs to your publish servers. For example the URL in the browser would be www.mysite.com/en/page1.html, and what gets passed back by dispatcher to the publish server must be /en/page1.html - you can't be using mod_rewrite to add the full paths back onto the URLs. 
  2. On your beta publisher you configure two rules for the Apache Resource Resolver Factory (persistent ID org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl). 
    1. /content/betasite/en/-/en/
    2. /content/mainsite/en-/en/
    3. /-/
  3. On your main site publisher you configure just one rule
    1. /content/mainsite/en-/en/
    2. /-/

That should generate the behavior you want. The resource resolver starts trying to find matches at the top of the list and returns the first matching resource. The one impact to this that you need to be aware of is that it can change your dispatcher flush behavior. Because you are caching with the shortended URL there will never be a match between path flushed and any HTML file so the only way anything will get flushed is via auto-invalidation. In addition if you are relying on the stat file for you flush design this approach may have an impact on that as well

View solution in original post

1 Reply
Paul_McMahon
Correct answer by
Level 8
Level 8

In order to do this with the out of the box resource resolver you need the following conditions:

  1. You would need to be passing back short URLs to your publish servers. For example the URL in the browser would be www.mysite.com/en/page1.html, and what gets passed back by dispatcher to the publish server must be /en/page1.html - you can't be using mod_rewrite to add the full paths back onto the URLs. 
  2. On your beta publisher you configure two rules for the Apache Resource Resolver Factory (persistent ID org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl). 
    1. /content/betasite/en/-/en/
    2. /content/mainsite/en-/en/
    3. /-/
  3. On your main site publisher you configure just one rule
    1. /content/mainsite/en-/en/
    2. /-/

That should generate the behavior you want. The resource resolver starts trying to find matches at the top of the list and returns the first matching resource. The one impact to this that you need to be aware of is that it can change your dispatcher flush behavior. Because you are caching with the shortended URL there will never be a match between path flushed and any HTML file so the only way anything will get flushed is via auto-invalidation. In addition if you are relying on the stat file for you flush design this approach may have an impact on that as well

View solution in original post