Category Archives: Uncategorized

Sling Context-Aware configuration

In the previous blog posting I outlined why there’s a need to store some configuration outside of OSGI and I named Sling Context-Aware Configuration (CA-Config) as a way to implement it.

CA-Config is a relative new feature of AEM (introduced with AEM 6.2) which stores the configuration inside the repository; but besides that it offers some features, which are handy in a lot of usecases:

  • You don’t deal with nodes and resources anymore, but only with POJOs. This kind of implementation completly hides where the configuration is stored, but the location of the config is stored as property on the node.
  • CA-Config implements an approach based on the repository hierarchy. If a configuration value is not found at the specified config location, the hierarchy is walked towards the root and further configurations are consulted, until a configuration is found or the root node is hit (in that case a default value for the configuration should be used).
  • the lookup process is very configurable, although the default one is sufficient in most cases.

A good example for this are content-related settings in a multi-tenant system. Imagine a multi-country and multi-language use-case (where for some countries multiple languages have to be supported); and in each country you should have different user groups, which act as approver in the the content activation process. In the past this was often done by storing it as part of the pages itself, but from a permission point of view it was possible for the authors to change it themselves (which typically only causes trouble). But with CA-Config this can be stored outside of the /content tree in /conf, but closely aligned to the content, and being able to match the weirdest requirements from a structural point of view; that means it is easily possible then have in one country 3 different approver groups for sections of the page, while in another just having 1 group covering all.

Another large usecase are sites, which are based on MSM livecopies. There is always content which is site-specific (e.g. contact adresses, names, logos, etc). And if this content is baked into a”regular” content page which is rolled out by MSM, the blueprint content will always overwrite the content which is specific to the livecopy. With CA-config it is easy possible to maintain these site-specific configurations outside of the regular content tree.

Before CA-Config all of this was implemented for very simple usecases using the InheritanceValueMap, which also implemented such a “walk-up-the-tree-if-the-property-is-not-found” algorithm. But it only looked up the direct parents and did not consider more structured property data as it is possible with CA-Config.

And there were a lot of custom implementations, which created “per site” configuration pages, typically next to the “homepage” page, and restricted access to it via ACLs or dispatcher/webserver/mapping rules. And of course these continue to work, but the access to these configuration data could be managed via the CA-Config as well (depending on the way how the data is stored either by just specifiying these as config path or by a custom lookup logic which can be configured for the CA-Config). And on top of that, these per-site configurations were per-site and not supporting the above mentioned case of having 3 different approver on different parts of the site.

So CA-Config is very flexible and efficient way to retrieve configuration data, which is stored in the repository. But it’s just for retrieving, there’s no prescribed way how the configuration data gets there.
While AEM comes with a configuration editor, it does not support writing the settings for CA-Config (at the moment it’s only designed for editable templates and workflows). has a content package for download which allows you to edit these configurations in the authoring UI.

In the next post I will outline how easy it is to actually use CA-Config.

Content and configuration

When developing for AEM, you are probably aware of the OSGI configuration. Every service stores its configuration within OSGI, and it’s very easy to extract the configuration from there for consumption. Also there are a number of best practices around deploying and maintaining these configurations.
This is very handy way to store information, and many developers tend to store all kind of configurable data inside OSGI.

But should all configuration stored inside OSGI? Let me show you some downsides of this approach:

  • OSGI configuration can be only changed through the “admin” user (or a member of the administrator group) and through the OSGI webconsole. Typically these accounts are owned by IT, because any access to the OSGI webconsole grants you a lot of chances to mess up the system. A normal user should not have access to the OSGI webconsole, neither from a permission point of view nor from the networking point of view (lock down /system/console URLs! Limit access to it to an admin network!)
  • Modifying configurations directly in the OSGI webconsole is not best practice; it’s OK to test something in the staging environment that way, but it should never be used to make changes in production. OSGI configuration should always be deployed in a content package, and not be changed via webconsole.
  • In many cases changing the configuration of a service causes a restart of this service and all other services depending on this service. That means, that doing such a change in a running system can cause lots of errors while services are stopping and starting.

Based on that, it is clearly visible, that not every configuration piece should be stored inside OSGI configuration.

The question is then: What should be stored inside OSGI configuration?

  • Configuration which has a global impact. For example the search path of the SlingMainServlet has the impact to break the complete application.
  • Configuration which should be tested. Testing means not only validating that a single operation is working (like a backend connection test), but which rather requires the run of some test cases.

And what should not be stored as OSGI configuration?

  • Configuration which is supposed to change not in accordance with any release or deployment cycle. For example an access token for an external system, which needs to be updated every month.
  • Configuration which should be changed by regular authors, but should not carried out by the admin user. The admin user is often owned by IT, and IT is typically very happy if they are not bothered with unrelated tasks from content authors.
  • Configuration which pertains to content. For example configuration if a contact email should be displayed as part of the page footer. Although it might be a global decision (probably not!) it should not be configured via OSGI.
  • Configuration is tight to a specific environment. For example you need to have the hostname of your site, but on UAT this name is of course different from production.

Starting with AEM 6.2 Sling Context-Aware Configuration (short: CA-Config) can be used to store and retrieve such configurations in a very efficient and sling-ish manner. More details in the followup posting. So stayed tuned.

AEM technical conferences in 2018

In the last years I attended a few conferences in the AEM space and I never got disappointed. On all of them I attended brilliant talks and presentation, meet with a lot of people and in general enjoyed well organized conferences.

In 2018 I will try again to visit at least one conference, and for convenience I collected here the AEM conferences I know. In case I missed one please leave a comment.
I ignore the local meetups here, because typically you won’t take a flight to attend such a meetup 🙂

In no particular order I found these conferences covering technical AEM topics in 2018:

  • Adobe Summit US (although it covers muuuuuuch more than just AEM) in Las Vegas, NV
  • Immerse 2018, a virtual conference
  • Evolve in San Diego, CA
  • AdaptTo in Potsdam, Germany; in 2018 at a larger venue than in the years before

At the moment I can already announce, that I will participate at the Adobe Summit (giving again a lab session). I am not sure if I will present at Immerse.

If you miss any conference with AEM related content, just speak up, I’ll add it to the list.

What’s new in Sling with AEM 6.3

AEM 6.3 is out. Besides the various product enhancements and new features it also includes updated versions of many open source libraries. So it’s your chance to have a closer at the version numbers and find out what changed. And again, quite a lot.

For your convenience I collected the version information of the sling bundles which are part of the initial released version (GA). Please note that with Servicepacks and Cumulative Hotfixes new bundle versions might be introduced.
If a version number is marked red, it has changed compared to the previous AEM versions. Bundles which are not present in the given version are marked with a dash (-).

For the versions 5.6 to 6.1 please see this older posting of mine.

Symbolic name of the bundle AEM 6.1 (GA) AEM 6.2 (GA) AEM 6.3 (GA) 2.1.4 2.1.6 (Changelog) 2.1.8 (Changelog) 2.9.0 2.11.0 (Changelog) 2.16.2 (Changelog) 0.9.0.R988585 0.9.0.R988585 0.9.0.R988585 1.3.6 1.3.14 (Changelog) 1.3.24 (Changelog) 0.0.1.R1582230 1.0.6 (Changelog) 2.2.0 2.2.0 2.2.0 1.1.0 1.2.0 1.2.0 1.3.2 1.3.2 1.3.8 (Changelog) 2.2.0 2.2.0 2.3.0 (Changelog) 1.0.2 1.0.2 1.0.0 1.0.2 (Changelog) 1.0.4 (Changelog) 1.0.0 1.0.0 1.0.0 2.0.10 2.0.16 (Changelog) 2.0.20 (Changelog) 4.0.2 4.0.6 (Changelog) 5.0.0 (Changelog) 1.0.0 1.0.4 1.0.6 (Changelog) 1.0.6 1.0.0 (Changelog) 1.2.0 (Changelog) 2.1.8 2.1.8 2.1.10 (Changelog) 2.2.2 2.4.0 (Changelog) 2.4.0 2.4.6 2.4.14 (Changelog) 2.5.2 (Changelog) 3.2.0 3.2.6 (Changelog) 3.2.6 1.0.0 1.0.0 1.0.2 (Changelog) 1.0.2 1.0.2 1.0.4 (Changelog) 1.1.2 (Changelog) 1.1.6 (Changelog) 1.0.10 (Changelog) 1.0.18 (Changelog) 1.1.0 1.2.6 (Changelog) 1.2.16 (Changelog) 1.0.0 1.0.0 1.0.0 0.1.0 0.3.0 0.3.0 0.1.1.r1678168 0.1.15.r1733486 0.2.6 2.4.2 2.4.6 (Changelog) 2.6.6 (Changelog) 3.5.5.R1667281 4.0.0 (Changelog) 4.2.0 (Changelog) 1.0.0 1.0.4 (Changelog) 1.1.0 (Changelog) 0.2.2 1.1.4 1.1.6 (Changelog) 1.2.0 (Changelog) 1.0.0 1.0.2 (Changelog) 1.2.0 (Changelog) 1.0.2 1.0.2 1.0.2 1.0.2 1.0.2 1.0.2 1.0.0 1.0.0 1.2.0 1.2.2 (Changelog) 1.2.4 (Changelog) 1.1.2 1.1.2 1.1.2 2.4.0 2.4.4 (Changelog) 2.5.6 (Changelog) 1.0.0 1.0.0 1.0.2 (Changelog) 3.6.4 3.6.8 (Changelog) 3.8.6 (Changelog) 1.1.2 1.1.2 1.1.2 1.0.0 1.1.0 1.1.0 1.1.0 3.1.16 3.1.18 (Changelog) 3.1.22 (Changelog) 0.1.0 0.1.0 0.1.0 2.2.0 2.3.0 (Changelog) 2.4.0 (Changelog) 2.2.2 2.3.2 (Changelog) 3.0.0 (Changelog) 2.1.0 2.1.10 2.1.10 2.1.10 1.2.2 1.3.4 (Changelog) 1.3.8 (Changelog) 2.0.0 2.0.0 2.0.0 1.0.2 1.0.2 1.0.2 1.1.2 2.5.0 2.7.4.B001 (Changelog) 2.9.2 (Changelog) 1.0.2 1.0.2 1.0.2 2.2.2 2.3.4 (Changelog) 2.3.8 (Changelog) 1.0.2 1.0.2 1.0.2 1.2.0 1.2.2 (Changelog) 1.2.2 1.1.0 1.2.2 (Changelog) 1.3.2 (Changelog) 1.1.0 1.2.2 (Changelog) 1.3.9.r1784960 (Changelog) 1.0.6 1.8.0 1.1.0 1.0.4 1.0.4 1.0.6 (Changelog) 1.0.0 1.0.0 1.0.0 1.0.0 1.0.0 1.0.0 1.2.9.R1675563-B002 1.3.0 (Changelog) 1.3.0 1.2.4 1.4.8 (Changelog) 1.5.22 (Changelog) 1.0.4 1.1.2 (Changelog) 1.2.1.R1777332 (Changelog) 2.1.6 2.1.8 (Changelog) 2.1.12 (Changelog) 2.0.28 2.0.36 (Changelog) 2.0.44 (Changelog) 2.0.12 2.0.14 (Changelog) 2.1.2 (Changelog) 2.0.16 2.0.28 2.0.30 2.1.6 2.1.8 2.2.6 2.2.4 2.2.4 2.2.6 2.0.6 2.0.6 2.0.6 1.0.2 1.0.18 1.0.32 1.0.8 1.0.8 1.0.4 1.0.10 1.0.18 1.0.0 1.0.6 1.0.10 1.0.18 1.1.2 1.2.0 1.2.2 1.2.4 1.0.0.Revision1200172 1.0.0.Revision1200172 1.0.0.Revision1200172 2.1.10 2.1.14 2.1.22 2.3.6 2.3.8 2.3.15.r1780096 2.3.6 2.4.2 2.4.10 1.3.6 1.3.8 1.3.8 0.0.1.Rev1526908 0.0.1.Rev1526908 0.0.1.Rev1764482 0.0.1.Rev1387008 0.0.1.Rev1387008 0.0.1.Rev1758544 1.0.2 1.0.2 1.1.0 0.0.2 1.0.2

AEM 6.3: set admin password on initial startup (Update)

With AEM 6.3 you have the chance to setup the admin password already on the initial start. By default the quickstart asks you for the password if you start it directly. That’s a great feature and shortens quite some deployment instructions, but it doesn’t work always.

For example, if you first unpack your AEM instance and then use the start script, you’ll never get asked for the new admin password. The same if you work in an application server setup. And if you do automatic installations, you don’t want to get asked at all.

But I found, that even in these scenarios you can set the admin password as part of the initial installation. There are 2 different ways:

  1. Set the system property “admin.password” to your desired password; and it will be used (for example add “-Dadmin.password=mypassword” to the JVM parameters).
  2. Or set the system property “admin.password.file” and pass as value the path to a file; when this file is accessible by the AEM instance and the contains the line “admin.password=myAdminPassword“, this value will be used as admin password.

Please note, that this only works on the initial startup. On all subsequent startups these system properties are ignored; and you should probably remove them or at least purge the file in case of (2).

Update: Ruben Reusser mentioned, that the Osgi Webconsole Admin password is not changed (which is used in case the repository is not running). So you still need to work on that.

What I check on code reviews

At several occassions I did code reviews on AEM projects  in the last months. I don’t do that exercise quite often, so I don’t have a real routine or checklists what to look at. But in the past I learned some lessons about how to write code for AEMs, so I hope I check relevant pieces. Feedback appreciated.

So let’s start with my top 10 items I look for:

  1. The use of “System.out.println()“, “System.err.println()” and “e.printStackTrace()” statements. Logging is cheap and easy, but obviously not easy enough, I still find these statements. They should be replaced, because these statements do not provide relevant metadata like time and class. And to be honest, people tend to look only at the error.log file, but not on stdout.log.
  2. Servlets bound to fixed paths. In most cases it should be replaced by binding either to a selector or to a resourcetype. The Sling documentation explains it quite well.
  3. The creation of dedicated sessions/ResourceResolvers (either admin sessions ot service user sessions) and if these sessions are properly closed. Although this should be common knowledge to AEM developers, there’s still code out there which doesn’t close resource resolvers or logs out sessions, causing memory leaks.
  4. The existence of long-running sessions. You shouldn’t write services, which open a session on activate and close them on deactive (see this blog post for the explanation). The only exception to this rule: JCR observation handlers.
  5. adaptTo() calls without proper null checks. adaptTo() is allowed to return null. There are cases where it can be neglected (in reality you’ll never have all occurrences of it checked), but in most cases it has to be checked to avoid NullPointerException.
  6. Log hygiene part 1: The excessive use of LOG.error(), when a is sufficient. Or even worse: LOG.error/info() instead of LOG.debug().
  7. Log hygiene part 2: Log messages without meaningful description. A log message has to contain relevant information like “with what parameter does this exception happen? At what node? Which request?”. Consider that some parts are always and implicitly logged (e.g. the thread name, which contains in case of a request the requested path), but you need to provide every other information which can be useful to understand the problem when found in the logs.
  8. The mixed usage of JCR and Sling API. Choose either one, but then stick to it. You should not have a method, which takes both a Session and a ResourceResolver as parameter (or other object from these domains).
  9. Performing string operations on paths. I already blogged about it.
  10. JCR queries. Are they properly used or can they get replaced by a short tree traversal?

So when you get through all of these quite generic items, your code is already quite well. And if you don’t have a specific problem which I should investigate, I will likely stop here. Because then you already proved, that you understand AEM and how to operate it quite well, so I wouldn’t expect major issues anymore.

I am sure that the personal background influences a lot the intuitive approach on code review. Therefor I am interested in your checklists and how it differs from mine. Just leave a comment, drop me a mail or tweet me 🙂

Let’s try to compile a list which we all can use to improve our code.

Application changes and incompatible features

In the lifecycle of every larger application there are many occasions where features evolve. In most cases the new version of a feature is compatible with earlier versions, but there are always cases where incompatible changes are required.

As example let me take the scenario the guys at KD WebConsult provided in their latest blog entry (which has inspired me to write this post, I have to admit). There is a component which introduces changes in the underlying repository structure, and the question is how to cope with that change in case of deployments.

I think that is a classical case of incompatible changes, which always result in additional effort; and that’s the reason why noone likes incompatible changes and tries to avoid them as much as possible. While in a pure AEM environment you should have the full control of all changes, it’s getting harder if you have system you depend on or systems depending on you. Then you run into the topic of interface lifecycle management. Making changes then gets hard and sometimes nearly impossible. You end up with supporting multiple versions of an interface at the same time. Duplicating code is then a way to cope with it. (The technical debt is not only on your side then, but also on the side of others no updating or able to update their use of the interfaces.)

So to come back to the KD Webconsult example I think that the cleanest solution is to build your component in a way, that it supports both the old and new the repository structure (their option 2). And if you are sure, that you don’t use the old structure anymore, you can safely remove the logic for it.

The thinking, that you can always avoid such situations and keep you code clean, is wrong. As soon as you are dealing with non-trivial setup (and AEM in an enterprise setup per se is a distributed application which comes along with other enterprisy requirements like high-availability) you have to make compromises. And taking technical debts for the time of a release or two is not necessarily a bad one if you can stick with standard processes (not changing deployment processes).