If this membership does not exist, the status dumps will timeout with a 401 Unauthorized error.
Troubleshooting Developer Console access
401 Unauthorized error when dumping status
If dumping any status a 401 Unauthorized error is reported, it means your user does not yet exist with the necessary permissions in AEM as a Cloud Service or the login tokens use are invalid or have expired.
To resolve the 401 Unauthorized issue:
Ensure your user is a member of the appropriate Adobe IMS Product Profile (AEM Administrators or AEM Users) for the Developer Console’s associated AEM as a Cloud Service Product instance.
Remember that Developer Console access 2 Adobe IMS Product Instances; the AEM as a Cloud Service Author and Publish product instances, so ensure the correct Product Profiles are used depending on which service tier requires access via Developer Console.
Log in to the AEM as a Cloud Service (Author or Publish) and ensure your user and groups have properly synced into AEM.
Developer Console requires your user record to be created in the corresponding AEM service tier for it to authenticate to that service tier.
Clear your browsers cookies as well as application state (local storage) and re-log into Developer Console, ensuring the access token Developer Console is using is correct and unexpired.
AEM as a Cloud Service Author and Publish services are comprised of multiple instances respectively in order to handle traffic variability and rolling updates without downtime. These instances are referred to as Pods. Pod selection in Developer Console defines the scope of data that will exposed via the other controls.
A pod is a discrete instance that is part of an AEM Service (Author or Publish)
Pods are transient, meaning AEM as a Cloud Service creates and destroys them as need
Only pods that are part of the associated AEM as a Cloud Service environment, are listed that environment’s Developer Console’s Pod switcher.
At the bottom of the Pod switcher, convenience options allow for selecting Pods by service type:
Status provides options for outputting specific AEM runtime state in text or JSON output. The Developer Console provides similar information as the AEM SDK’s local quickstart’s OSGi Web console, with the marked difference that Developer Console is read-only.
Oak Indexes provide a dump of the nodes defined beneath /oak:index. Keep in mind this does not show merged indexes, which occurs when an AEM index is modified.
Oak Indexes help in debugging by:
Listing all Oak Index definitions providing insights into how search queries are executed in AEM. Keep in mind, that modified to AEM indexes are not reflected here. This view is only helpful for indexes that are solely provided by AEM, or solely provided by the custom code.
Java Packages is used to trouble shoot Bundles not be starting because of unresolved imports, or unresolved classes in scripts (HTL, JSP, etc). If Java Packages reports no bundles export a Java package (or the version does not match that imported by an OSGi bundle):
Ensure your project’s AEM API maven dependency’s version matches the environment’s AEM Release version (and if possible, update everything to the latest).
If extra Maven dependencies are used in the Maven project
Determine if an alternative API provided by the AEM SDK API dependency can be used instead.
If the extra dependency is required, ensure it’s provide as an OSGi bundle (rather than a plain Jar) and it is embedded in your project’s code package, (ui.apps), similar to how the core OSGi Bundle is embedded in the ui.apps package.
Servlets is used to provide insight as to how AEM resolves a URL to a Java servlet or script (HTL, JSP) that ultimately handles the request. This functionality is the same as AEM SDK’s local quickstart’s Sling Servlet Resolver at /system/console/servletresolver.
Servlets helps in debugging determining:
How a URL is decomposed into its addressable parts (resource, selector, extension).
What servlet or script a URL resolves to, helping identify mal-formed URLs or mis-registered servlets/scripts.