Composum Blog

various aspects of the Composum world

Remote Resource Provider

There is a nifty debugging feature hidden in the configurations, which can allow you to inspect the JCR repository of a faulty instance if it serves Sling standard GET servlet requests with JSON, or is accessible via WevDAV. That helps if the server you need to debug does not carry a browser (e.g. an AEM as a Cloud Service publish instance) or too broken to even run the browser.

Hans-Peter Störr
03.04.2022

To diagnose trouble in a Sling instance, a JCR browser like the Composum Nodes Browser or the CRX DE Lite in Adobe Experience Manager is an invaluable tool. But what do you do if the system does not have a browser installed or even browser doesn't run? If the system is configured such that it serves requests like /content/something.1.json with the default Sling GET servlet, there is a trick you can pull from the Composum toolbox. You can fire up a plain Sling Starter running the Composum Browser (or just use an existing system running the Browser), and add a configuration there that effectively mounts the Sling repository of the system you want to debug into the Sling repository of this starter:

This will let you view the content of the remote repository available at https://systemtodebug.example.net/ below /remote/systemtodebug in the local repository. The username given has to be a local user of that system, and can be omitted if you want to view just the anonymously visible content there (or there is no login available, as in the case of AEMaaCS publish instances).

Please take care that the "Ignored Path Patterns" do not match the "Provider Root Path", or nothing will happen.

Caution: for every resource presented in the resource tree of the browser this submits a JSON request to the remote system. So this is for debugging only, and it'd probably be a bad idea to do e.g. a tree traversal since that'd swamp that system with requests.