AEM 6.5 Vanity URL - /libs/granite/dispatcher/content/vanityUrls.html 404 | Community
Skip to main content
N
NitroHazeDev
Level 9
January 9, 2023
Solved

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

  • January 9, 2023
  • 2 replies
  • 2406 views

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,

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by cshawaus

@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.

2 replies

Shashi_Mulugu
Community Advisor
Shashi_MuluguCommunity Advisor
Community Advisor
January 9, 2023

@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/main/archetype/dispatcher.ams/src/conf.dispatcher.d/available_farms/999_ams_publish_farm.any

 

 

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

 

 

    N
    NitroHazeDevAuthor
    Level 9
    January 9, 2023

    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
      cshawausAccepted solution
      Level 2
      January 10, 2023

      @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.

        N
        NitroHazeDevAuthor
        Level 9
        January 10, 2023

        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
        cshawaus
        Level 2
        January 10, 2023

        @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.

          Terms & ConditionsAccessibility statement

          Loading footer...