AEM is a robust platform built upon proven, scalable, and flexible technologies. This document give a detailed overview of the various parts that make up AEM and is intended as a technical appendix for a full-stack AEM developer. It is not intended as a getting-started guide. If you are new to AEM development, please consult the Getting Started Developing AEM Sites - WKND Tutorial as a first step.
Before diving into the core technologies of AEM, Adobe recommends completing the Getting Started Developing AEM Sites - WKND Tutorial.
As a modern content management system, AEM relies on standard web technologies:
The underlying content repository and business logic layers are built around Java technologies:
The Java Content Repository (JCR) standard, JSR 283, specifies a vendor-independent and implementation-independent way to access content bi-directionally on a granular level within a content repository. The specification lead is held by Adobe Research (Switzerland) AG.
The JCR API 2.0 package,
javax.jcr.* is used for the direct access and manipulation of repository content.
AEM is built upon a JCR.
Apache Jackrabbit Oak is an implementation of a scalable and high-performance hierarchical content repository for use as the foundation of modern world-class web sites and other demanding content applications, conforming to the JCR standard.
Jackrabbit Oak (also referred to simply as Oak), is the implementation of the JCR standard upon which AEM is built.
AEM is built using Sling, a Web application framework based on REST principles that provides easy development of content-oriented applications. Sling uses a JCR repository, like Apache Jackrabbit Oak, as its data store. Sling has been contributed to the Apache Software Foundation - further information can be found at Apache.
Using Sling, the type of content to be rendered is not the first processing consideration. Instead the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering. This provides excellent support for web content authors to build pages which are easily customized to their requirements.
The advantages of this flexibility are apparent in applications with a wide range of different content elements, or when you need pages that can be easily customized. In particular, when implementing a Web Content Management system such as AEM.
See Discover Sling in 15 minutes for the first steps for developing with Sling.
The following diagram explains Sling script resolution: it shows how to get from HTTP request to content node, from content node to resource type, from resource type to script and what scripting variables are available.
The following diagram explains all the hidden, but powerful, request parameters you can use when dealing with the
SlingPostServlet, the default handler for all POST requests that gives you endless options for creating, modifying, deleting, copying and moving nodes in the repository.
Sling is content-centric. This means that processing is focused on the content as each (HTTP) request is mapped onto content in the form of a JCR resource (a repository node):
Due to its content-centric philosophy, Sling implements a REST-oriented server and thus features a new concept in web application frameworks. The advantages are:
In Sling, processing is driven by the URL of the user request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL.
If we analyze the following URL:
We can break it down into its composite parts:
Using the principles of URL decomposition:
The following figure illustrates the mechanism used, which will be discussed in more detail in the following sections.
With Sling, you specify which script renders a certain entity (by setting the
sling:resourceType property in the JCR node). This mechanism offers more freedom than one in which the script accesses the data entities (as an SQL statement in a PHP script would do) as a resource can have several renditions.
The request is broken down and the necessary information extracted. The repository is searched for the requested resource (content node):
Sling also allows things other than JCR nodes to be resources, but this is an advanced feature.
When the appropriate resource (content node) is located, the sling resource type is extracted. This is a path, which locates the script to be used for rendering the content.
The path specified by the
sling:resourceType can be either:
Relative paths are recommended by Adobe as they increase portability.
All Sling scripts are stored in subfolders of either
/apps (mutable, user scripts) or
/libs (immutable, system scripts), which will be searched in this order.
A few other points to note are:
The list of script engines supported by the given instance of AEM are listed on the Felix Management Console (
Using the previous example, if the
hr/jobs then for:
.html(default request types, default format)
/apps/hr/jobs/jobs.esp; the last section of the
sling:resourceTypeforms the file name.
/apps/hr/jobs/jobs.pdf.esp; the suffix is added to the script name.
/apps/hr/jobs/jobs.print.esp; the selector is added to the script name.
sling:resourceTypehas been defined then:
../content/corporate/jobs/developer.htmlwould generate a search in
.txt), HTML (
.html) and JSON (
.json), all of which will list the node’s properties (suitably formatted). The default rendition for the extension
.res, or requests without a request extension, is to spool the resource (where possible).
/apps/sling/servlet/errorhandlerfor customized scripts
If multiple scripts apply for a given request, the script with the best match is selected. The more specific a match is, the better it is; in other words, the more selector matches the better, regardless of any request extension or method name match.
For example, consider a request to access the resource
Assuming we have the following list of scripts in the correct location:
Then the order of preference would be (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).
In addition to the resource types (primarily defined by the
sling:resourceType property) there is also the resource super type. This is generally indicated by the
sling:resourceSuperType property. These super types are also considered when trying to find a script. The advantage of resource super types is that they may form a hierarchy of resources where the default resource type
sling/servlet/default (used by the default servlets) is effectively the root.
The resource super type of a resource may be defined in two ways:
sling:resourceSuperTypeproperty of the resource.
sling:resourceSuperTypeproperty of the node to which the
sling:resourceSuperType = a
sling:resourceSuperType = b
sling:resourceType = c
sling:resourceType = c
sling:resourceSuperType = a
The type hierarchy of:
[ c, b, a, <default>]
[ c, a, <default>]
This is because
/y has the
sling:resourceSuperType property whereas
/x does not and therefore its supertype is taken from its resource type.
Within Sling, scripts cannot be called directly as this would break the strict concept of a REST server; you would mix resources and representations.
If you call the representation (the script) directly you hide the resource inside your script, so the framework (Sling) no longer knows about it. Thus you lose certain features:
POST.jspscript in your
This uses the Sling API package,
org.apache.sling.*, and tag libraries.
A final consideration is the need to reference existing elements within the scripts.
More complex scripts (aggregating scripts) might need to access multiple resources (for example navigation, sidebar, footer, elements of a list) and do so by including the resource.
To do this you can use the
sling:include("/<path>/<resource>") command. This will effectively include the definition of the referenced resource.
OSGi (Open Services Gateway Initiative) defines an architecture for developing and deploying modular applications and libraries (it is also known as the Dynamic Module System for Java). OSGi containers allow you to break your application into individual modules (are jar files with additional meta information and called bundles in OSGi terminology) and manage the cross-dependencies between them with:
These services and contracts provide an architecture which enables individual elements to dynamically discover each other for collaboration.
An OSGi framework then offers you dynamic loading/unloading, configuration and control of these bundles - without requiring restarts.
Full information on OSGi technology can be found at the OSGi website.
In particular, their Basic Education page holds a collection of presentations and tutorials.
This architecture allows you to extend Sling with application specific modules. Sling, and therefore AEM, uses the Apache Felix implementation of OSGi. They are both collections of OSGi bundles running within an OSGi framework.
This enables you to perform the following actions on any of the packages within your installation:
See Configuring OSGi for AEM as a Cloud Service for more information.
The following list gives an overview of the structure you will see within the repository.
/apps- Application related; includes component definitions specific to your website. The components that you develop can be based on the out of the box components available at
/content- Content created for your website.
/home- User and Group information.
/libs- Libraries and definitions that belong to the core of AEM. The sub-folders in
/libsrepresent the out-of-the box AEM features. The content in
/libsmay not be modified. Features specific to your website should be made under
/tmp- Temporary working area.
/var- Files that change and are updated by the system; such as audit logs, statistics, event-handling.
Changes to this structure, or the files within it, should be made with care. Make sure that you fully understand the implications of any changes you make.
You must not change anything in the
/libs path. For configuration and other changes copy the item from
/apps and make any changes within