HTL/Sightly Exception Handling - to support a smoothly degeneration of a Page being on display in case of a single AEM/Sling Component fails

[markusm21]

Hi,

I'm neither a Sling nor an AEM Genius. We want to migrate from CQ 5.6.1 with JSPs to AEM 6.2 with Sightly and Sling Models.

I have this wishful thinking, and maybe I'm too blind to see, but a central feature seems lacking to me in HTL, which is the smooth degeneration of a Page if one of the Components (either being on a parsys or hard coded in the templates) is running wild (during initialization, or during the rendering of actual content - using either the Use or Sling Models API, of which the content typically gets cached for a certain amount time in the Dispatcher Cache - at least for us).

I spent quite some time searching on the AEM forum and the internet for a suitable solution - without results, so I decided to ask this question as a "last resort".

Typical to an enterprise scenario combing JCR with none JCR Backends, it is likely to happen sooner or later for external content integration (REST-, SOAP-API, DB Access), that it fails upon actual data retrieval, due to some unavailability issues, thus provoking an Exception in the respective AEM Component for display as a net effect.

Side notes: 
I assume that the respective Components behave more or less like "portlets", which means they are pretty independent of the rest of the content on the page.
A Good practice for us (and in general?) is to propagate an Exception you cannot handle (thus being a Runtime Exception ...) to the upper layers where they are treated as a cross cutting concern... In our case the UI Layer (aka Sling/AEM Components/the Sling Scripting Framework with logic backed by Java Classes).

I looked in the Sling Documentation, which seemed promising at first, however, the Exception Handling using https://sling.apache.org/documentation/the-sling-engine/errorhandling.html - Uncaught Throwables - doesn't seem to be WCMMode agnostic:

If the WCMMode is "edit" it comes close to what we want (instead of a Stacktrace, we would like to let an author define either a general error message or an empty string for production - i.e. not rending the component in the end on failure).
If the WCMMode is "disabled" as on a Publisher, the whole page is replaced by the content provided by the Error Handler being invoked, which is not acceptable for the client (all or nothing isn't an option).

I looked through the WCM Use, Sling Models and SlingScript and -Resolver API, however, I feel like they all run short in supporting what we actually want...
To have an own implementation of a parsys with special Exception Handling seems to be only a part of the Solution, as scripts to be included in the HTL can be hard coded - hence it doesn't provide for a general solution.

To put it the other way round, I look for a clever replacement in HTL for the JSP javax.servlet.jsp.tagext.TryCatchFinally that we used to harness by supplying an own JSP Tag Library with Backing Bean Support (~ Sling Models) in CQ 5.6.1.

Actually, I wonder why google searches for "Sling Models Exception Handling" or "HTL/Sightly Exception Handling" don't show any useful/relevant results ... :-(

Any clues that go into the direction of gentle degeneration in the context of HTL/Sightly Component Failures are highly appreciated :-)

Thank you very much in advance.

Cheers,

Markus

[MC_Stuff]

Hi Markus,

   Your description is clear on things you are looking. If i come across any thing later will let you on,  Top of my head thinking you might need to end up writing an filter Process the filter chain but only catch errors, the way it is implemented in edit mode . 

But don;t you thing such requirement will make page not cache able ?

Thanks,

[markusm21]

Hi Mc Stuff,

thanks for the reply. 

Yes there are always two sides of the medal.

Our JSP Taglib Code sets a header in the context of an Exception, that should prevent the Dispatcher from Caching the Response for that scenario, i.e. when one of the Components during the initial rendering fails (the snippets that can actually be cached if all things go smooth ...).

Basically this is what we call in the context of a partial failure:

private void preventDispatcherCache() { ServletResponse response = getPageContext().getResponse();   if(HttpServletResponse.class.isInstance(response)) { HttpServletResponse httpResponse = (HttpServletResponse) response;      if(!httpResponse.isCommitted()) { httpResponse.setHeader("Dispatcher","no-cache");      } else {LOG.warn("could not set 'Dispatcher: no-cache' header, because response was already commited.");      } } }

This means that as long as the Exception won't go away, the page is not cached, hence to Publishers experience more traffic on the down-side.

On the up-side the page gently degenerates in the eye of the customer.

Cheers,

Markus

[MC_Stuff · Accepted solution]

Hi Markus,

   Thanks for the update & glad able to get brake through.  Logic of preventDispatcherCache make sense & needs to be plugged some how.   it is nice enhancement if it become part of ComponentErrorHandlerImpl to not cache.  If you agree please file enhancement request at https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues 

Thanks,

[markusm21]

I deleted my last comment by accident (as it appeared twice in the history), so here it is again for completeness:

Hi MC Stuff,

you pointed me into the right direction of using a Servlet Filter. By paying closer attention to the Stacktrace in case of an Exception I realized the class com.day.cq.wcm.core.impl.WCMDeveloperModeFilter being involved.

By searching the internet I found out that the ACS Commons Project actually solved the "gentle degeneration" issue already on a Component level for the various WCMModes.

https://adobe-consulting-services.github.io/acs-aem-commons/features/component-error-handler/index.h...

I installed it, fiddled with the Config and successfully verified the Solution.

Thanks again for heading me into the right direction with your Feedback :-)

Cheers,

Markus

P.s.: Next I will need to check, how the Caching of a Partial Failed Response is handled in the Dispatcher Context. Could be that the ComponentErrorHandlerImpl of the ACS Commons Project needs to be amplified for our use case (to direct the Dispatcher not to cache the Response). 

I now filed a Feature Enhancement Request on github to include an optional dispatcher no-cache header in the context of partial failure of a Component on the page, so that the AEM Dispatcher won't cache the Response.

https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/972

Cheers,

Markus

[MC_Stuff]

Hi Markus,

  Thanks for filling the enhancement request. Appreciate it.  Hopefully ACS will consider this.

Thanks,