With xpath being deprecated since JCR 2, SQL2 remains the most effective way to perform raw queries against Jackrabbit. The two ways I've used are described below:

  1. Using resourceResolver.findResources - I.E. The Sling Way
  2. Using queryManager.createQuery - I.E. The Jackrabbit Way

There's pros and cons to both, so let's dive in...


Here we can see a simple query being executed and returning an iterable that can be adapted to any object. This works brilliantly for simple queries. Now what if we want to paginate or limit these posts? Enter queryManager...


With a few changes, we can now leverage the methods query.setOffset and query.setLimit. 

While there are many advantages to this approach, there is one big disadvantage: There's no simple way to adapt a plain JCR NodeIterator into a resource without writing a custom adapter. However, we can do something very clever in Sightly...

By using data-sly-resource, we can grab each child node using our path and render it using our given resourceType.



AEM 6.1 introduced new CSRF protections for Servlets. If you're using OOTB AEM jQuery, this is mostly handled for you. I want to cover the use case for not using jquery or the granite.csrf.standalone ClientLib.


I've been making it a point to reduce my dependency on jQuery. With an AEM author, you'll never get 100% away from it, but it's possible to do on publish if you're doing typical WCM type sites. Also, with my current project, we are keeping the site as dependency free as humanly possible.


The trick is to send an async XHR request to the token endpoint (/libs/granite/csrf/token.json), pass that token on to your servlet as a header property called "CSRF-Token".

Below you see a fairly basic Sightly Component. Comments are inline.

And a a simple servlet to return the information back...

Update: I've added a proper github project here.

In classic UI, it was easy to specify the options property on a selection xtype. 

This made getting dynamic data into a dropdown very easy. Simply point the options property to /path/to/resource.infinity.json and you were done. In Granite, things don't work this easy.

There are two approaches that I found. 1) Use a listener. 2) Use ACS Commons GenericList / Datasource solution.

The ACS commons solution works great, but it's a bit rigid on the data structure. I used it as my starting point for the solution below. 

My solution is a 3 step process, requires no JS and no external dependencies.

Step 1

Make a datasource component. It only needs to have one jsp file in it...

Step 2

Add a datasource node to your dialog property. Read the gist for pertinent info.

Step 3


Scripting AEM Oak Compaction

January, 10 2016

Offline compaction is still the Adobe recommended way of compacting Oak. Below is a script to help automate the entire process. Please keep in mind that you will need to download a version of Oak Run that matches your repository version.

  1. Shutdown AEM
  2. Find Old Checkpoints
  3. Remove Unreferenced Checkpoints
  4. Compact Oak
  5. Restart AEM

Each step will log basic information into a file using the current date. The stop and start processes specifically write the exact time they were kicked off.

Note: I've taken the liberty of adding a few arguments to the compaction process to help with memory issues. You can read about tar memory mapping here.


There's been a significant improvement to SAML with AEM 6.1 that is worth mentioning: Multiple OSGi configurations.

The problem

If you've gone through my AEM ADFS SAML tutorial, you know that SAML works tremendously well for author integrations. On 6.0, having a single OSGi configuration ties you to a single SAML IDP per AEM instance. In the case of ADFS, this meant not being able to use multiple URLs for SAML authentication.

The solution

By having multiple OSGi configurations in 6.1, you are no longer forced to choose a site or AEM instance to support. You can mix and match sites, AEM instances (author, publish, dispatch), and content nodes. This gives you complete control over how you trigger and accept SAML assertions.

Something to remember

Authentication in AEM is handled by the resource being requested. This means a parent resource SAML entry will override any sibling resource.

Bad OSGi SAML Paths:


In this case, having a root node authentication handler will completely override any authentication handler declared for a child node. This can be frustrating if you want to have all publish requests hit one IDP and have site-1's requests hit another IDP. With clever apache rewrites you can work around this limitation.

A better scenario would be handle authentication at a sibling level:

Good OSGi SAML Paths:


In this scenario, site one is not a child of site two, and thus can have a different authentication handler / IDP / return URL.