AEM 6.5 Vanity URL - /libs/granite/dispatcher/content/vanityUrls.html 404

[NitroHazeDev]

All,

We are on 6.5.12 and migrated from 6.4. A lot of messages with "INFO" status, come up with /libs/granite/dispatcher/content/vanityUrls.html. org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Resource /content/XXX/libs/granite/dispatcher/content/vanityUrls.html not found

Any idea why and how this can be resolved? Much appreciated in advance,

Regards,

[Shashi_Mulugu]

@NitroHazeDev as you said, you have migrated from AEM 6.4 to AEM 6.5.12, you might have created a new AEM archetype based project and used dispatcher module from it.. if you check the dispatcher module, you can see vanityurl is enabled and this will hit publisher every nth seconds as configured. If you are not using vanities, please disable it.

https://github.com/adobe/aem-project-archetype/blob/4fcb4a95528602279024e6903316508d09770ee3/src/mai...

https://experienceleague.adobe.com/docs/experience-cloud-kcs/kbarticles/KA-17463.html?lang=en

[NitroHazeDev]

Thanks @Shashi_Mulugu  I saw it in the ams pub and project specific farm any. While i believe I need to disable at both places if not used , ..but if used , how do I work towards handling it ? 
Is this due to the new archetype thing in 65 since I don’t believe it existed in 64? 
i happened to see the /content/site name appended before the vanity path /content/XXX/libs/granite/dispatcher/content/vanityUrls.html and no path within AEM crxde at libs/granite/dispatcher/content/vanityUrls 

[cshawaus · Accepted solution]

@NitroHazeDev The simplest thing to try would be to download and install the vanityurls-components package in your publish environment. The latest archetypes come with this component enabled by default in the dispatcher configuration which is likely the cause of the log messages.

If you find you don't need support for vanity URLs, you can simply remove it from your dispatcher configuration entirely.

[NitroHazeDev]

Thanks @cshawaus , any mappings that need to be done for the vanity urls if it is being used? and should it go to the pubs only via package install and that's it? If vanity urls are not used, should i just comment out the below lines in the custom farm and the ams farm any file?

Is there a way for me to know that vanity urls are in use? would it be searching by the sling:vanityPath via querybuilder? or checking if package was installed? we migrated from 64 to 65.

The path /libs/granite/dispatcher/content/vanityUrls.html does not seem to exist on 65 pubs crxde but somehow there is a page with vanity path set, would it still work without the package?

/vanity_urls {
/url "/libs/granite/dispatcher/content/vanityUrls.html"
/file "/tmp/vanity_urls"
/delay 300
}

[cshawaus]

@NitroHazeDev That is correct. This package is only for the publish server(s) as that is the only point (as OOTB) that interacts with vanity URLs. You could technically enable it for the author server too if you have it running via the dispatcher, but it would not provide any real benefits.

To check if your content uses vanity paths you can use the QueryBuilder debugger in your author server.

/libs/cq/search/content/querydebug.html?_charset_=UTF-8&query=path%3D%2Fcontent%0D%0Atype%3Dcq%3APage%0D%0A1_property%3Djcr%3Acontent%2Fsling%3AvanityPath%0D%0A1_property.operation%3Dexists

If you find you aren't using it, you can safely remove the lines mentioned above from your dispatcher configuration. If any pages do make use of a vanity path without the necessary configurations/packages being available, you will likely not see anything break but the dispatcher won't skip the filters which is what happens with the configuration enabled in the dispatcher.

[NitroHazeDev]

Thanks @cshawaus , I did validate with a similar query and appears that there was an occurrence .. strangely when I added a vanity path /abc , it worked on auth and pub but via dispatcher on pub even with the package installed it did not render the page . Weird behavior