BREAKING NEWS: Exadel named a Leader in this Forrester Agile Software Development Service Providers report... Learn more!  

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.

NEW! Want to test new technologies like blockchain, AI, mobile, chatbot, and machine learning models? Learn about our Innovation Lab.