Tech Tips

Read our other AEM tips

Migrating to newer versions of a software platform can (and often is) a challenging and interesting task. One needs to carefully track what was changed in a platform as well as its components, because even a small change in a framework API can cause something to break.

One example from our experience came up after upgrading from AEM 6.2 to AEM 6.4. After the upgrade, one of our services just stopped working. We checked the Web Console Configuration (at /system/console/configMgr) and noticed something unusual.

This is how the configuration of our com.acme.www.core.service.MyServiceFromBundleA looked on AEM 6.2:

This is how it looked after the AEM 6.4 upgrade when the service stopped working:

As you can see, our service residing in Bundle A got a configuration binding to another bundle’s (Bundle B) jar. The service MyServiceFromBundleA started working fine when we manually unbound the wrong configuration right from the Web Console Configuration window. But after the next redeployment the wrong configuration appeared to be bound again, and the MyServiceFromBundleA service stopped working again.

After some research we figured out that Bundle B contained a service that was doing this:

This is what OSGi Javadoc says about this method:

“…If the Configuration object for this PID does not exist, create a new Configuration object for that PID, where properties are null. Bind its location to the calling bundle’s location.”

So, the container was actually behaving fine according to the spec. It was creating a configuration and binding it to Bundle B, the calling bundle.

In order to fix the issue we had to pass a second null parameter to the getConfiguration method to prevent the creation of the wrong configuration.

Author: Denis Glushkov

How can we help you?
Contact Us
Linux 4.4.0-189-generic #219-Ubuntu SMP Tue Aug 11 12:26:50 UTC 2020 x86_64