URLs on publish instance do not respect Sling Mapping

[stefanseifert]

scenario: we want to to and end-to-end integration test using AEM Testing client involving both author and publish/dispatcher and replication between them. on publish/dispatcher a "multi domain management AEM mapping" is defined similar as described here:
https://helpx.adobe.com/experience-manager/kb/multi-domain-management-aem-mappings-for-url-shortening---aem-6-.html

that means that

• all URLs on publish are shortened (e.g. https://my-publish/en.html instead of https://my-publish/content/mysite/en.html)
• and direct access to the full access is denied (https://my-publish/content/mysite/en.html leads to HTTP 404)

with this setup it's currently not easy possible to write an integration test without hardcoding the short urls in the test. the CQClient class has concepts for mapping paths to URLs, but this does not take into account a sling mapping configuration applied on the publish instances testing against. thus when using built-in methods like CQAssert.assertCQPageExistsWithTimeout they internally alsways build paths with the full URL and fail.

of course it's not easy for the CQClient instance to read out the real mapping configuration form the running AEM instance (esp. because there are multiple ways to configure this, and a mapping config can get really complex). but it would be nice when it can be configured in a simplified way for the integration test similar to configuring the author/publish URLs.

are there any plans/concepts to support this properly?

[volteanu]

That's a really interesting case, @stefanseifert !

I think there are two aspects to this that could be tested, depending on the intention:

1. test the multi-domain management configuration in AEM or
2. test features like replication on AEMs that have multi-domain management configured

For 1. I'd say the best would be to have a dedicated client (i.e. UrlShorteningClient extends CQClient) that encodes the expected mapping so you can test it matches actual configuration, of course by checking the effects. One example would be:

• create a page under /content/mysite/en.html
• publish the page
• do a get for /content/mysite/en.html on publish which is resolved by UrlShorteningClient to https://my-publish/content/mysite/en.html

For 2. it might indeed be tricky, especially that getting the actual mapping config is difficult, as you pointed out. The way we handled this in similar situations was to support a system property which can change the behavior of the clients used in tests: https://github.com/adobe/aem-testing-clients/blob/aem-cloud/src/main/java/com/adobe/cq/testing/junit/rules/ConfigurableInstance.java

If the mapping is easy to express (e.g. through a regex), this can be included in the system property as a static configuration. Sensible defaults should also fit most of the cases (like the example you provided). Otherwise, a smarter client/configuration would be to load this mapping from AEM itself, which I don't know how feasible it is and if it's worth.

BTW, this seems a sling feature, do you think it would make sense to have this improvement in https://github.com/apache/sling-org-apache-sling-testing-clients/ ?

[stefanseifert]

yes, i think this would fit in sling testing clients as sling mapping is mainly a sling feature.
not sure if it really makes sense to have a new client implementation than, or if it should be something that can be configured/activated on the existing clients.

i think for the purpose of the tests it should be possible to express the shortening with a simple config like a regex, it should be possible to provide it from outside e.g. system environment parameter.