Author: Blair Robertson

I am Senior Solution Architect here at TBSCG specialising in getting projects done. I work on projects around two Enterprise CMS - Adobe AEM and HP Teamsite - however I get involved in all parts of the technical landscape.

The other day I had some problems with the user profile synchronisation in an AEM6.1 with AEM Communities (using Sling Distribution to sync the user profiles). Essentially I had seen some inconsistencies between a couple of the publish nodes and I wanted to check that out.

All the accounts I was interested in where stored under sub-folders of /home/users/community (in the randomly associated list).

Because of the 10k+ users I was not able to do the infamous “-1” json depth selector. So I had to walk the tree

So let’s break this down. Think of it like the command line. JQ treats part of the filter (the part in single quotes above) as a separate command that takes whole JSON objects. We start with the to_entries[]

to_entries takes a object and creates an array of objects with the 2 properties “key” and “value”

And with a stream of objects we can use select to filter only the objects we want (in this case “rep:AuthorizableFolder”)
The ? at the end of .value[“jcr:primaryType”]? means that the property does not have to exist

I am working on a project that is using AEM6 and an AEM FeaturePack for Adobe Campaign. As this is a FP, the APIs are not available through the normal public repositories. I needed to get the project to build so the solution is to use the Archive Servlet. This worked great and the project compiled and installed into AEM fine.

I then needed to use HTTPClient to make some external webservice calls, so looked at what was exposed by the Archiva servlet, found that AEM already uses 4.3.3, added the dependency, mvn clean install, code compiled, happy days.

Until I went to install it into AEM. Then I was getting weird bundle dependency issues:

Have used this 2 times within 1 month on 2 different clients with 2 different application servers, so it must be worth sharing.

Both times I had a need to monitor some values available to me from JMX, and then chart those results afterwards. And in both cases having to make requests to the SysAdmins to setup the monitoring in their normal tools would have taken days/weeks. And this needed to be running by that afternoon…you know how it is.

First case was when we were handling a set of load testing for a client whom we host. The applications where hosted on JBoss EAP and the developers needed to monitor the some of the core features (infinispan caches, datasources, jms) as well as some custom MBeans they had developed.

Second case was an AEM6 application where we wanted to watch some basics like the thread count, heap usage, cpu load while we were running JMeter tests.

I have it outputing to STDOUT because that allows me to use rotatelogs that comes with Apache HTTPD to break the logs out into 4hr blocks easily.

This is output format is obviously a really easy format to work with, so as a separate process I have a Perl script that takes these raw logs and turns them into some nice and basic Google Charts that can be viewed locally.

A quick change around and a tiny bit of jQuery allowed generation of JSON files with the data, that could be loaded into a parent page. This allowed multiple data points to be graphed together:

At the moment the JMXClient can only read attributes, but for AEM I wanted to log the workflow count during an Author performance test. Luckily with AEM JMX is also exposed over HTTP.

So a simple shell script with curl and I was able to output the workflow count into the same format as the JMXClient output and append it to the logs, allowing the use of the same scripts to generate some graphs:

Configuration

The MBeans attributes to watch is done via a TAB separated configuration file in this format:

The line starting with “Q>” tells the JMXClient to perform a query to get the real MBeanObject name. This is useful if that can change. In the example above the id is an integer that might be different between servers. On the JBoss configurations I also used to remove the need to hardcode any application versions under the deployment sub area where they would normally be my-app-1.0.3.war for example

I recently performed an audit for a client of their AEM development and deployment. Part of that audit covered their AEM page renderers and components. They had started their development with AEM 6 which allowed them to use the new Sightly interpretor for their components. The following is some items I picked up that are generic enough to share.

Sightly != JSP

It may sound obvious, but Sightly is not JSP. This means a S(l)ightly different mindset is required when developing these files. This mostly revolves around the use of control structures that are such a definite part of Java in JSP, but are more elegant in Sightly.

data-sly-unwrap as control structures

In this audit I repeatedly saw the use of an extra <div> just to wrap a conditional. This is basically taking the logic from a JSP script and converting it to Sightly. Imagine the following code in Sightly:

Pass WCMUse Objects to templates

The client was following best practice by using templates for their repetitive code, but in some cases I noticed they were passing a WCMUse class name through to the template so that it could be instantiated with a data-sly-use. However in all cases I could find this WCMUse class was already instantiated in the Sightly file calling the template – resulting in two instantiations of the object.