Adobe-Consulting-Services
Cannot register component. The component name 'com.adobe.acs.commons.<Component>' has already been registered by Bundle
Required Information
- [x] AEM Version, including Service Packs, Cumulative Fix Packs, etc: AEMaaCS 2023.11.14227.20231108T162349Z
- [x] ACS AEM Commons Version: 6.3.2
- [x] Reproducible on Latest? yes
Expected Behavior
ACS AEM Commons runs without errors in log
Actual Behavior
Once bundle with ACS AEM Commons installed in error log I can observe errors like
[FelixLogListener] com.adobe.acs.commons.<SERVICE> bundle com.adobe.acs.acs-aem-commons-bundle:6.3.2 (630)[com.adobe.acs.commons.<SERVICE>] : Cannot register component (org.apache.felix.log.LogException: org.osgi.service.component.ComponentException: The component name 'com.adobe.acs.commons.<SERVICE>' has already been registered by Bundle 630 (com.adobe.acs.acs-aem-commons-bundle) as Component of Class com.adobe.acs.commons.<SERVICE>)
org.apache.felix.log.LogException: org.osgi.service.component.ComponentException: The component name 'com.adobe.acs.commons.<SERVICE>' has already been registered by Bundle 630 (com.adobe.acs.acs-aem-commons-bundle) as Component of Class com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl
for example
[FelixLogListener] com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl bundle com.adobe.acs.acs-aem-commons-bundle:6.3.2 (630)[com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl] : Cannot register component (org.apache.felix.log.LogException: org.osgi.service.component.ComponentException: The component name 'com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl' has already been registered by Bundle 630 (com.adobe.acs.acs-aem-commons-bundle) as Component of Class com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl)
org.apache.felix.log.LogException: org.osgi.service.component.ComponentException: The component name 'com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl' has already been registered by Bundle 630 (com.adobe.acs.acs-aem-commons-bundle) as Component of Class com.adobe.acs.commons.wcm.impl.AuthorUIHelperImpl
It looks like the package is trying to run twice resulting in an error. At first glance the ACS functions are working fine but there are quite a few similar errors in the log. _
Steps to Reproduce
I faced error with cloud instance during ACS update from 5.3.4 to 6.x.x(6.3.2).
Bellow few pom snippets
<dependency>
<groupId>com.adobe.acs</groupId>
<artifactId>acs-aem-commons-all</artifactId>
<version>${acs.commons.version}</version>
<classifier>cloud</classifier>
<type>zip</type>
</dependency>
<embedded>
<groupId>com.adobe.acs</groupId>
<artifactId>acs-aem-commons-all</artifactId>
<type>zip</type>
<target>/apps/company-packages/container/install</target>
<!-- <filter>true</filter> -->
<!-- <isAllVersionsFilter>true</isAllVersionsFilter>-->
</embedded>
Keep in mind that "isAllVersionsFilter"/"filter" during test might be disabled due to "filevault-package-maven-plugin" version (1.0.3- not supported, 1.3.6 - latest one)
Links
https://adobe-consulting-services.github.io/acs-aem-commons/pages/maven.html#aem-as-a-cloud-service https://jackrabbit.apache.org/filevault-package-maven-plugin-archives/1.3.6/generate-metadata-mojo.html https://jackrabbit.apache.org/filevault-package-maven-plugin-archives/1.0.3/generate-metadata-mojo.html
Hello colleagues, same happens on our production project: both on Author and Publish AEM Version, including Service Packs, Cumulative Fix Packs, etc: AEMaaCS (on both)
- 2023.12.14538.20231205T165334Z
- 2023.12.14697.20231215T125030Z ACS AEM Commons Version: 6.3.2 Reproducible on Latest? yes
hi, any updates on this? have the same issue. AEM: 2024.4.15977.20240418T174835Z-240400 ACS AEM Commons Version: 6.6.0
@rdb987 , @serg-kovalenko, @Victar
- If you look in Dev Console, are you seeing only a single ACS Commons bundle? Or are there multiple of the same bundle at different versions?
- Does this happen for many/every ACS Commons OSGi service/component? If its only for some,can you provide a short list of others so we could look at commonalities in them?
- Does this happen when the AEM CS pod starts up?
- Does this only happen on true AEM CS - or does it happen on AEM SDK as well?
@kwin any thoughts off the top of your head what could be causing this...?
I would assume that this happens because the services are started once the main bundle becomes active and somehow once the bundle fragment gets bound. This sounds like a Felix bug to me. The component lifecycle chapter in the OSGi spec doesn't really talk about fragments though: https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-component.lifecycle
@adamcin was able to help determine it was this: https://github.com/Adobe-Consulting-Services/acs-aem-commons/commit/302aadee81429a73c82c3f67c9ff02b8c556dc37#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R221
The *.xml reprocesses all the services, as they are explicitly enumerated already.
The instruction https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/e2c2bfaf5107e768f87cc6d145dccb0a31cd6a62/pom.xml#L255 is not supposed to be merged with something else. It works fine for the bundle fragment, but somehow not for the main bundle.... I currently don't know why Bnd behaves like that...
Absent any bnd support for using only the wildcard entry for Service-Component, we might consider filing a bug ticket for felix since there is no reason this logic shouldn’t be able to tell that it is re-reading an xml file versus reading a new file with a duplicate component descriptor: https://github.com/apache/felix-dev/blob/b6fff2adcc1afee039f0f60713032363144ad0fa/scr/src/main/java/org/apache/felix/scr/impl/BundleComponentActivator.java#L385-L407
@davidjgonzalez @kwin I think another possibility is that, from the perspective of the ComponentRegistry, the bundle modified event being triggered by the fragment installation may be calling ScrExtension.start() without first destroying the previous ScrExtension state...i.e., unloading the ComponentMetadata instances that were registered by the initial bundle activation.
This is an example stack trace:
[FelixLogListener] com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl bundle com.adobe.acs.acs-aem-commons-bundle:6.4.0 (619)[com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl] : Cannot register component (org.apache.felix.log.LogException: org.osgi.service.component.ComponentException: The component name 'com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl' has already been registered by Bundle 619 (com.adobe.acs.acs-aem-commons-bundle) as Component of Class com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl)
org.apache.felix.log.LogException: org.osgi.service.component.ComponentException: The component name 'com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl' has already been registered by Bundle 619 (com.adobe.acs.acs-aem-commons-bundle) as Component of Class com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl
at org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:240)
at org.apache.felix.scr.impl.BundleComponentActivator.validateAndRegister(BundleComponentActivator.java:448)
at org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:407)
at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:283)
at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:218)
at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:592)
at org.apache.felix.scr.impl.Activator.access$200(Activator.java:74)
at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:460)
at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
at org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
at org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4847)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2363)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.base/java.lang.Thread.run(Thread.java:834)
The AbstractExtender.modifiedBundle() method won't destroy the state before reloading the components if the host bundle is ACTIVE or STARTING.
https://github.com/apache/felix-dev/blob/76344a4f9681f46c7db43ef9b089f0fcbcbb3e79/scr/src/main/java/org/apache/felix/scr/impl/AbstractExtender.java#L143-L170
Specifically WRT to the Service-Component configuration not overwriting the value, it appears it has something to do with:
-plugin.felixscr: org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir="$(basedir)/target/classes";log=error
If you comment this out, then you get the expected Service-Component: OSGI-INF/*.xml in the MANIFEST.MF ... wondering if its quicker to move teverything over to OSGi annotations and remove the Felix SCR plugin entirely (assuming that is the fix)
Specifically WRT to the Service-Component configuration not overwriting the value, it appears it has something to do with:
-plugin.felixscr: org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir="$(basedir)/target/classes";log=errorIf you comment this out, then you get the expected
Service-Component: OSGI-INF/*.xmlin the MANIFEST.MF ... wondering if its quicker to move teverything over to OSGi annotations and remove the Felix SCR plugin entirely (assuming that is the fix)
@davidjgonzalez I don't think that will help actually. It is likely that that is simply hiding the Felix SCR components from BND, so it is not even generating the XML files at all.
Regardless, I think a Felix bugfix would be more expedient, because making a change to the acs-aem-commons poms and/or bnd will only affect subsequent artifact versions. I have an interest in eliminating this excessive logging for all affected versions without waiting for customers to change their code.
I raised bndtools/bnd#6108 for this.
@kwin Based on what you and @davidjgonzalez have described, I think it may be the org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin which is not removing the overlaps, not aQute.bnd.component.DSAnnotations.
https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr.bnd-1.9.6/src/main/java/org/apache/felix/scrplugin/bnd/SCRDescriptorBndPlugin.java
private void addServiceComponentHeader(Analyzer analyzer, String components) {
Set<String> descriptorsSet = new HashSet<String>();
String oldComponents = analyzer.getProperty("Service-Component");
parseComponents(descriptorsSet, oldComponents);
parseComponents(descriptorsSet, components);
StringBuilder sb = new StringBuilder();
Iterator<String> it = descriptorsSet.iterator();
while (it.hasNext()) {
sb.append(it.next());
if (it.hasNext()) {
sb.append(",");
}
}
String comps = sb.toString();
log.info("Setting Service-Component header: " + comps);
analyzer.setProperty("Service-Component", comps);
}
private void parseComponents(Set<String> descriptorsSet, String components) {
if (components != null && components.length() > 0) {
for (String comp : components.split(",")) {
comp = comp.trim();
if (comp.length() > 0) {
descriptorsSet.add(comp);
}
}
}
}
@adamcin - maybe im not following, but it seems like its org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin generating the overlaps. I was saying that if we removed all Felix SCR annotations from the code, then we could get rid of org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin entirely, which should in turn remove the explicit, double Service-Components.
If this can be fixed in the projects w/ the problems thats of course most desirable - but im not sure how quickly those teams can provide a fix -- and if the fix turns out to be something in AEM/Felix - how fast that fix could be deployed to AEM CS.
Is modifying the plugin code as simple as checking if String oldComponents = analyzer.getProperty("Service-Component"); isnt empty, and if it isnt assume its been set as desired, and skip adding the "new" components? Or would that break other usecases im not aware of?
@adamcin - maybe im not following, but it seems like its
org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugingenerating the overlaps. I was saying that if we removed all Felix SCR annotations from the code, then we could get rid oforg.apache.felix.scrplugin.bnd.SCRDescriptorBndPluginentirely, which should in turn remove the explicit, double Service-Components.If this can be fixed in the projects w/ the problems thats of course most desirable - but im not sure how quickly those teams can provide a fix -- and if the fix turns out to be something in AEM/Felix - how fast that fix could be deployed to AEM CS.
Is modifying the plugin code as simple as checking if
String oldComponents = analyzer.getProperty("Service-Component");isnt empty, and if it isnt assume its been set as desired, and skip adding the "new"components? Or would that break other usecases im not aware of?
@davidjgonzalez Yes, you are right. Switching to DS annotations completely will likely fix this going forward, but I hesitate to recommend that refactoring at this time because of the risk of introducing bugs.
On the other hand, I already have an approval on the PR I submitted to apache/felix-dev for FELIX-6699, so we're already making progress on that approach.
It is correct that the Scr-Bnd-Plugin is to blame here: https://github.com/apache/felix-dev/blob/81edc6e48db29feae5d0deb0af23719f50ddcb2b/tools/org.apache.felix.scr.bnd/src/main/java/org/apache/felix/scrplugin/bnd/SCRDescriptorBndPlugin.java#L212
I asked in https://bnd.discourse.group/t/overwrite-manifest-header-written-by-bnd-plugin/444/1 for a way how to fix the wrong manifest header in bnd itself (with another plugin).
@adamcin Thanks for raising the Felix PR but I still think we should emit proper headers in ACS AEM Commons bundles in the first place.
Hi, I plan to start an SCR release with the fix https://github.com/apache/felix-dev/pull/311 this week. I believe the SCR behavior is incorrect with respect to wild cards here. Thanks for raising the issue and providing the fix.
It is correct that the Scr-Bnd-Plugin is to blame here: https://github.com/apache/felix-dev/blob/81edc6e48db29feae5d0deb0af23719f50ddcb2b/tools/org.apache.felix.scr.bnd/src/main/java/org/apache/felix/scrplugin/bnd/SCRDescriptorBndPlugin.java#L212
I asked in https://bnd.discourse.group/t/overwrite-manifest-header-written-by-bnd-plugin/444/1 for a way how to fix the wrong manifest header in bnd itself (with another plugin).
@adamcin Thanks for raising the Felix PR but I still think we should emit proper headers in ACS AEM Commons bundles in the first place.
@kwin I agree, so please continue looking for ways to fix this in tooling. I just don't think this particular issue (which is only generating excessive log messages) should increase the priority of broad SCR-to-DS annotations refactoring of ACS AEM Commons classes, because any bugs or breaking changes that are introduced by that refactoring will invariably have a higher severity than this issue.
@adamcin what artifact will be updated w/ the fix -- will it be in a version bump to:
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.scr.bnd</artifactId>
<version>1.9.6</version>
</dependency>
It looks looks like the artifact the fix is going into is: <artifactId>org.apache.felix.scr</artifactId> at 2.2.12 -- but we dont directly use that in ACS Commons i dont think?
@adamcin ahhh! gotcha - makes much more sense now. Any insights on what AEM CS/6.5 SP version it will be in?
@davidjgonzalez Very unlikely AEM 6.5 will ever get the fix. 6.5.20 is still with org.apache.felix.scr 2.1.30 from 2021 (DS 1.4), while the latest is 2.2.10 (DS 1.5).