[
https://issues.apache.org/jira/browse/FELIX-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Adamcin updated FELIX-6699:
--------------------------------
Description:
When a bundle's Service-Component header contains explicit paths and wildcard
paths, it is possible for an explicit descriptor entry to be parsed twice, if
it is also matched by a wildcard entry. This results in an ERROR level log
similar to that described in FELIX-2325. The use case which requires this mix
of wildcard and non-wildcard entries is probably rare, but such is the
situation with
[https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3241]
In this situation, bnd is used to package the host bundle, and so the
descriptors for the DS components contained within it are listed explicitly in
the Service-Component header value generated by the bnd tool.
Additionally, the project packages some optional component descriptors in a
sidecar fragment bundle which cannot define its own Service-Component header.
In order for SCR to load the optional components only when the fragment is
attached, they must be listed by the host bundle's Service-Component header,
but only implicitly by using a wildcard, so that their absence is not logged
when the fragment is not attached.
Here is an example stack trace:
{code:java}
[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) {code}
was:
When a bundle's Service-Component header contains explicit paths and wildcard
paths, it is possible for an explicit descriptor entry to be parsed twice, if
it is also matched by a wildcard entry. This results in an ERROR level log
similar to that described in FELIX-2325. The use case which requires this mix
of wildcard and non-wildcard entries is probably rare, but such is the
situation with
[https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3241]
In this situation, bnd is used to package the host bundle, and so the
descriptors for the DS components contained within it are listed explicitly in
the Service-Component header value generated by the bnd tool.
Additionally, the project packages some optional component descriptors in a
sidecar fragment bundle which cannot define its own Service-Component header.
In order for SCR to load the optional components only when the fragment is
attached, they must be listed by the host bundle's Service-Component header,
but only implicitly by using a wildcard, so that their absence is not logged
when the fragment is not attached.
> [DS] Excessive ERROR logging when Overlap in Service-Component header between
> wildcard and non-wildcard locations
> -----------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-6699
> URL: https://issues.apache.org/jira/browse/FELIX-6699
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.2.10
> Reporter: Mark Adamcin
> Priority: Major
> Labels: patch-available
> Fix For: scr-2.2.12
>
>
> When a bundle's Service-Component header contains explicit paths and wildcard
> paths, it is possible for an explicit descriptor entry to be parsed twice, if
> it is also matched by a wildcard entry. This results in an ERROR level log
> similar to that described in FELIX-2325. The use case which requires this mix
> of wildcard and non-wildcard entries is probably rare, but such is the
> situation with
> [https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3241]
> In this situation, bnd is used to package the host bundle, and so the
> descriptors for the DS components contained within it are listed explicitly
> in the Service-Component header value generated by the bnd tool.
> Additionally, the project packages some optional component descriptors in a
> sidecar fragment bundle which cannot define its own Service-Component header.
> In order for SCR to load the optional components only when the fragment is
> attached, they must be listed by the host bundle's Service-Component header,
> but only implicitly by using a wildcard, so that their absence is not logged
> when the fragment is not attached.
> Here is an example stack trace:
> {code:java}
> [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) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
