Adobe CQ 5.5 – Platform Architecture Refurbish

This year I got an early Christmas gift: a beta version of the upcoming Day CQ 5.5 – the newest incarnation of the Adobe Digital Enterprise Platform. The previous version was released soon after Adobe acquired the product and had but subtle touches made to it. This one seems more like the first stage in a major review of the whole architecture. Let’s see what changed and how it affects migration and future work on the platform.

Everything is running in OSGi

This has been rumoured about for quite a while and came more as a relief than a surprise. CQ 5.5 is finally a 100% OSGi application. Now, what does that really mean?

For as long as I remember (and that dates back to the days of Communiqué 4), CQ has been a set of two webapps running in a standalone servlet engine (by default: CQSE). The first application was CRX, and the second WCM – in CQ5 called “Launchpad”. Launchpad is an OSGi application with Sling, WCM, DAM and the rest of the family. In the two-webapp setup, Sling is accessing CRX using JNDI via an in-memory service provider. Well, it works, but feels awkward – we’ve got OSGi and yet, we use it only for a part of the application. Of course, one could argue that it is a sound failover – even when your OSGi goes wahoomi, you still have access to CRX over HTTP (so e.g. data backup is still an option), but I’ve always asked myself – is it really worth it?

It seems that it wasn’t – in CQ 5.5 everything lives inside OSGi. CQSE is an OSGi bundle (provides org.osgi.service.http and javax.servlet) and so is CRX that provides the repository as an OSGi service. RMI / JNDI are still available, but don’t seem to be used in the stack (client repository configuration is gone).

What does it mean migration-wise? Not much, really. All my applications are already working in OSGi, accessing CRX via Sling and not depending on JNDI, and even if yours did depend on JNDI – it’s still there as an option. The only scenario where something would have to be rewritten is when one had another webapp on CQSE – but I can’t imagine why would anyone want to do that. I’m not sure, though, what happens with deployments on different servlet engines (Tomcat, Weblogic, etc.). Maybe CQ5.5 will be available as a webapp too – I think we’ll have to wait for the official release notes and supported platforms to answer that.

Consoles clean-up

Another change that it brought is clean-up in consoles. /admin is now gone – CQSE is configured in Felix Configuration Manager. If you are looking for /crx, it is now /crx/explorer, and some CRX tools are exposed as separate OSGi servlets or are integrated into Felix Web Console. A very good side-effect is that now we can change instance’s admin password in a single place – CRX.

Package manager also got unified – there’s only one, and it’s the CRX one: /crx/packmgr (the WCM one – /etc/packages.list.html – is no more). Functionally nothing changed, but I’ll have to update one of my Maven plugins that was relying on the old console to deploy CQ packages.

Next steps

That’s more or less all I’ve figured out by now. Unfortunately, I didn’t get the updated documentation yet, so some areas leave me with more questions than answers. In the next few days I’ll be hunting API changes and testing feature compatibility to estimate the effort of upgrading our customers when this version is out. I’ll post my findings here as I go. Just bear in mind that it’s still beta, and everything is subject to change. Some features may not even make it into the final release. Having said that – I can’t imagine big changes like putting OSGi on the bottom of the stack being reverted. After all, it’s too good to throw it away.