Skip to main content
New Participant
March 23, 2017

ACS Commons Error Page Handling Issues On Dispatcher

  • March 23, 2017
  • 13 replies
  • 5974 views

I was wondering if someone could explain why ACS Commons Error Handler is not functioning properly on the Dispatcher?

Here are some of the tests I have done:

Accessing the publisher with the following URL's it will resolve the en-us specific 404 page properly:

http://publisher:4503/content/en-us/nopage
http://publisher:4503/content/en-us/products/nopage.html

When I access the dispatcher with the URL's below it does not resolve the page with the custom 404, but instead with a blank page (Console does show 404). I can set the error-page.system-path to point to the /content/en-us/404 page and it would behave correctly as a catch all.

http://qa.crown.com/content/en-us/nopage
http://qa.crown.com/content/en-usnopage


When I access the dispatcher with the following URL's it will resolve the 404 page (Seems the period is needed after en-us)
http://qa.crown.com/content/en-us.htmlblabla
http://qa.crown.com/content/en-us.nopage
http://qa.crown.com/content/en-us/products.nopage
http://qa.crown.com/content/en-us/products.htmlblabla

On the dispatcher I did set DispatcherPassError to 0 so that the dispatcher spools all error responses to the client. I have also tested this without any rewriterules and it results with the same issue.

Thanks

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

13 replies

p0990m
New Participant
October 25, 2017

Hi ,

I am facing similar issue in calling custom pages using acs-commons error handler in dispacther url. What has been observed is in my local I have setup the dispatcher, where my custom error pages are coming up in the localhost:8080/. Where as in my dev instance , dev author ip and publish ip, custom error pages are coming up for 500, 404 whereas for endurl i.e disptacher url ,where we have a junction name after the domain "https://domainname/junction/content/abc/home.html" custom error pages are not showing up? Is it something because of junction name before /content. Can someone suggest on this?

edubey
New Participant
October 25, 2017

What's the junction name?

Rewrite the URL at dispatcher level so that AEM can map to a resource. It should work then.

Thanks

ksuren
New Participant
April 26, 2017
ksuren
New Participant
April 28, 2017

ksuren wrote...

This has been fixed https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/957

The updated version https://github.com/Adobe-Consulting-Services/acs-aem-commons/releases/tag/acs-aem-commons-3.8.4  should have the fix 

 

If you still see any issue, try these:

1.       Update ACS Commons to the new version 3.8.4
2.       Open http://<ip>:<port>/system/console/bundles  and look for “Apache Sling Commons FileSystem ClassLoader”. Make a not of the bundle number. It is generally 305
3.       Open terminal/shell/ssh, delete the “classes” folder from “/mnt/crx/publish/crx-quickstart/launchpad/felix/bundle305/data”
4.       Go back to AEM, and open any page, then an invalid url. By this time, the bundle should be recreated and “active”.

 

 

joerghoh
Employee
March 27, 2017

Can you set the dispatcher loglevel to 3 ("debug") and redo the requests which fail to produce the proper error page?

Jörg

New Participant
March 28, 2017

The first request does trigger the 404 correctly, but 2nd one does not. I attached the debug level logs from the dispatcher.

Thanks

MC_Stuff
New Participant
March 29, 2017

Does not sound like a webserver issue.  Are you using the latest ACS?  Also is request protocoll changed http vs https.

Can you send requesttracker file by accessing both aem directly & dispather?

kautuk_sahni
Employee
March 27, 2017

DId you check the suggestion provided by MC Stuff ?

~kautuk

Kautuk Sahni
New Participant
March 27, 2017

I'm pretty sure Directory Browsing is enabled I went through the httpd.conf and set Options to FollowSymLinks and Indexes. The Directory settings under the Virtual Host I'm testing already had this set.

Is there a way I can verify for sure this is working on the Dispatcher?