Debugging

The logs

Locally these live in crx-quickstart/logs; on Cloud Service you download them from Cloud Manager or tail them with the AIO CLI.

• error.log — application logging and stack traces. Your first stop, almost always.
• request.log — one line in and one out per request, with duration and status. The place to find slow requests.
• access.log — HTTP access in a standard format.
• stdout.log / stderr.log — startup output, including problems too early for the normal logging framework.

On Cloud Service, Dispatcher and CDN logs are separate downloads. When a request behaves oddly you often need the CDN log (did it hit the cache?) and the AEM log (what did AEM do?) side by side.

# Tail Cloud Service logs from the command line
aio aem:rde:logs                     # for an RDE
# or download per-environment log files from Cloud Manager

Custom log files

Rather than drowning your project's logging in error.log, configure a Sling Logging Logger writing your package to its own file at DEBUG, while the root logger stays at INFO. It is an OSGi factory configuration, so it ships in ui.config and can be run-mode scoped — DEBUG on dev, WARN on production.

Remote debugging

Start the local instance with the JVM debug agent:

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 \
     -jar aem-author-p4502.jar

Then create a Remote JVM Debug configuration in your IDE pointing at localhost:5005, attach, and set breakpoints in your Sling Models and services as you would in any Java application.

The OSGi consoles

Four pages cover most diagnosis:

• /system/console/bundles — is my bundle Active? If not, which import is unsatisfied?
• /system/console/components — is my component satisfied? If not, which reference failed to bind?
• /system/console/slingmodels — is my model registered, and for which resource types and adaptables?
• /system/console/configMgr — what configuration actually applied?

Two more worth knowing:

• /system/console/status-slingresourceresolver — shows resource resolver mappings, invaluable when a URL resolves somewhere unexpected.
• /system/console/jmx — JMX beans, including repository statistics and session counts. Rising session counts point at unclosed resolvers.

Cloud Service tooling

Production does not expose the Felix console. Instead:

• Developer Console — reachable per environment from Cloud Manager. Provides bundle and component status, Sling Model registrations, resource resolution testing, and — genuinely useful — query performance analysis that flags traversals.
• Repository Browser — a read-only view of the repository on a Cloud Service environment. This is your replacement for CRXDE Lite in the cloud: you can confirm whether content and structure are actually as you expect, without any ability to modify them.
• Build and deployment logs in Cloud Manager, for failures that never reach a running instance.

A workable order of attack

1. Is the code deployed and running? Bundle Active, component satisfied.
2. Is the content what you think it is? Repository Browser or CRXDE.
3. Is the configuration what you think it is? configMgr — check the run mode.
4. What does the log say? error.log around the timestamp.
5. Is a cache involved? Response headers, then the Dispatcher docroot.
6. Only then reach for a debugger.