Expand my Community achievements bar.

SOLVED

AEM 6.3 Configuration bound to wrong bundle launchpad:resources/install/0/org.apache.sling.scripting.core-2.0.44.jar

Avatar

Level 2

Hi Community,

Want to share resolution of an issue I was facing with AEM 6.3 regarding wrong bundle binding causing components not working as expected.

Problem - Component configuration bound to launchpad:resources/install/0/org.apache.sling.scripting.core-2.0.44.jar where as per AEM 6.3 it should be unbound. Due to this wrong binding component doesn't get activated with correct OSGI config.

Cause - In our application code which is running fine on AEM 6.1, we were using

Configuration conf = sling.getService(org.osgi.service.cm.ConfigurationAdmin.class).getConfiguration(configName);

Whenever a page was loading, the above code is being executed. Above line return Configuration object which has bundle location set to some default value

launchpad:resources/install/0/org.apache.sling.scripting.core-2.0.44.jar

Fix- Set the bundle location to null in the code as follows. This will fix the problem.

Configuration conf = sling.getService(org.osgi.service.cm.ConfigurationAdmin.class).getConfiguration(configName);

if (null = conf) {

conf.setBundleLocation(null);

}

Cheers,

Deepak

1 Accepted Solution

Avatar

Correct answer by
Level 2

@chinnainturi

Above solution works for us. See if you have the same problem.

View solution in original post

3 Replies

Avatar

Correct answer by
Level 2

@chinnainturi

Above solution works for us. See if you have the same problem.

Avatar

Level 2

Just a little correct,

Fix- Set the bundle location to null in the code as follows. This will fix the problem.

Configuration conf = sling.getService(org.osgi.service.cm.ConfigurationAdmin.class).getConfiguration(configNam e);

if (null != conf) {

conf.setBundleLocation(null);

}

Avatar

Level 1

dbdigital04​: where exactly did you implemented this change in the service? Also, we are facing this issue for jcrinstall:/apps/install/aem.parent,core-x.y.z.jar

We are using ACS-Commons 'com.adobe.acs.commons.replication.dispatcher.impl.DispatcherFlushRulesImpl' to invalidate cache and this configuration somehow gets binded to an old jar version.