You may already know CQ can render HTML pages with .html extension, I'd like to show you how to tell CQ to render pages with other custom extension. For example, instead of responding to http requests end with .html, we want CQ responds to requests end with .foo.

In order to tell CQ to be able to deal with a custom request with a special page extension (e.g., .foo), you need to

Implement a component JSP file to render the page with .foo extension, and

Tell CQ that .foo extension is acceptable.

Here's the details of what you need to do:

#1) Implement component JSP to render page with .foo extension

Like many other CQ5 component, you should have known how to implement a CQ5 component in JSP, and what to name (according to url-to-script resolution rules) it so that it'll be used to render the page being requested. In our example case to render page with .foo extension, the JSP component can be named as foo.jsp. If you're not familiar with url-to-script resolution in Sling, please refer to other articles and tutorials first then come back to this article. In this post, I'd like to focus on the next step which is essential and is not quite clearly documented by Adobe.

#2) Tell CQ that .foo extension is acceptable

This has to be achieved by creating a file under /libs/foundation/components/primary/cq/Page/. Specifically, using our .foo extension example, we need to create the following file named Page.foo.jsp if you want request to pages of .foo extension to be acceptable by CQ:

Please note, for unknown reason, use the following line without the full path of proxy.jsp or with extra return characters at the end may lead you to some unknown 500 Error on rendering the page, so don't:

<%@include file="proxy.jsp" %>[return]

Therefore, I highly suggest you to make sure you don't have extra carriage return at the end and use the full path to reference proxy.jsp in Page.foo.jsp if possible. Otherwise, you may encounter 500 Internal Server Error as I did using CQ 5.6.1.

Conclusion

Suppose you have implemented a component JSP named foo.jsp (#1) and have a Page.foo.jsp file set up as mentioned above (#2), as a result, user request to http://...whatever/..../[pagename].foo will be handled by proxy.jsp, which in terms will somehow pass the control to the component jsp file named foo.jsp referenced by the resourceType (or resourceSuperType) property of the page's content node.

References

This information is still applicable in more recent AEM versions. The primary nodetype handlers need to include a proxy to the content resource for a given extension, so that resource type specific handlers may have a chance to run. This conflicts, of course, with use of the default text renderer, if you happened somehow to have a use for it.

Reply

Srikanth

11/6/2018 02:52:34 pm

Hi,
This works great in AEM 6.1.
I think in 6.4 '/libs/foundation/components/primary/cq/Page/proxy.jsp path changed to '/libs/cq/Page/proxy.jsp'. So I changed the folder structure accordingly, but it still not working as expected.

Reply

Srikanth

11/7/2018 09:39:58 am

It's working as expected after changing the path from '/libs/foundation/components/primary/cq/Page/proxy.jsp to '/libs/cq/Page/proxy.jsp'.
In AEM 6.4.