[
https://issues.apache.org/jira/browse/KARAF-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169185#comment-17169185
]
Robert Varga edited comment on KARAF-6625 at 7/31/20, 10:35 PM:
----------------------------------------------------------------
Thinking about this a bit more, this actually might be a maven-bundle-plugin or
bnd bug. In this particular case the factory component referenced is in the
same bundle.
As per 112.5.5 of Compendium (R6 and R7):
{noformat}
SCR must register a Component Factory service as soon as the component factory
becomes satisfied. {noformat}
and
{noformat}
The Component Factory service must be registered under the name
org.osgi.service.component.ComponentFactory with the following service
properties:
• component.name - The name of the component.
• component.factory - The value of the factory attribute.
{noformat}
Hence while the ComponentFactory requirement is not *directly* provided by the
bundle, it is provided *indirectly* via the bundle's interaction with SCR: once
the factory component (defined by the bundle) becomes satisflied, SCR will
register the ComponentFactory on the bundle's behalf. I therefore think
maven-bundle-plugin should have generated the matching Provide-Capability
manifest entry.
An alternative interpretation would be that SCR bundle potentially provides
ComponentFactory and therefore it is a Felix bug, as it does not specify it.
I lean towards the former, as that allows more precise control over
Requires/Provides: we can bind on the actual service properties (i.e. provide
constrained to @Component.factory=XXX, just as the bundle's requirement is
constrained to @Reference.target = "(component.factory=XYZ)".
[~jbonofre] what is your opinion on this analysis?
was (Author: nite):
Thinking about this a bit more, this actually might be a maven-bundle-plugin or
bnd bug. In this particular case the factory component referenced is in the
same bundle.
As per 112.5.5 of Compendium (R6 and R7):
{noformat}
SCR must register a Component Factory service as soon as the component factory
becomes satisfied. {noformat}
and
{noformat}
The Component Factory service must be registered under the name
org.osgi.service.component.ComponentFactory with the following service
properties:
• component.name - The name of the component.
• component.factory - The value of the factory attribute.
{noformat}
Hence while the ComponentFactory requirement is not *directly* provided by the
bundle, it is provided *indirectly* via the bundle's interaction with SCR: once
the factory component (defined by the bundle) becomes satisflied, SCR will
register the ComponentFactory on the bundle's behalf. I therefore think
maven-bundle-plugin should have generated the matching Provide-Capability
manifest entry.
An alternative interpretation would be that SCR bundle potentially provides
ComponentFactory and therefore it is a Felix bug, as it does not specify it.
I lean towards the former, as that allows more precise control over
Requires/Provides: we can bind on the actual service properties (i.e. provide
constrained to component.factory=XXX, just as the bundle's requirement is
constrained to @Reference.target = "(component.factory=XYZ)".
[~jbonofre] what is your opinion on this analysis?
> feature:install fails for bundles with SCR Factory Components
> -------------------------------------------------------------
>
> Key: KARAF-6625
> URL: https://issues.apache.org/jira/browse/KARAF-6625
> Project: Karaf
> Issue Type: Bug
> Components: karaf
> Affects Versions: 4.2.8
> Reporter: Robert Varga
> Assignee: Jean-Baptiste Onofré
> Priority: Major
>
> This issue has been reported in the thread here:
> [https://mail-archives.apache.org/mod_mbox/karaf-user/201809.mbox/%[email protected]%3e]
> If a bundle is created using stock maven-bundle-plugin (4.2.1), without
> specifying:
> {noformat}
> <_dsannotations-options>norequirements</_dsannotations-options>{noformat}
> and is using Factory Components
> ([https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e39673]
> , but it works the same way for R6), it results in MANIFEST.MF containing:
> {noformat}
> Require-Capability:
> osgi.service;filter:="(objectClass=org.osgi.service.component.ComponentFactory)";effective:=active
> {noformat}
> This is not handled properly at feature:install time and resulting in:
> {noformat}
> karaf@root()> feature:install odl-mdsal-binding-runtime
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root:
> missing requirement [root] osgi.identity;
> osgi.identity=odl-mdsal-binding-runtime; type=karaf.feature;
> version="[6.0.0.SNAPSHOT,6.0.0.SNAPSHOT]";
> filter:="(&(osgi.identity=odl-mdsal-binding-runtime)(type=karaf.feature)(version>=6.0.0.SNAPSHOT)(version<=6.0.0.SNAPSHOT))"
> [caused by: Unable to resolve odl-mdsal-binding-runtime/6.0.0.SNAPSHOT:
> missing requirement [odl-mdsal-binding-runtime/6.0.0.SNAPSHOT] osgi.identity;
> osgi.identity=org.opendaylight.mdsal.binding-runtime-osgi; type=osgi.bundle;
> version="[6.0.0.SNAPSHOT,6.0.0.SNAPSHOT]"; resolution:=mandatory [caused by:
> Unable to resolve org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT:
> missing requirement
> [org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT] osgi.service;
> filter:="(objectClass=org.osgi.service.component.ComponentFactory)";
> effective:=active]]
> at
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:392)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:378)
> at
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:332)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:393)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
> resolve odl-mdsal-binding-runtime/6.0.0.SNAPSHOT: missing requirement
> [odl-mdsal-binding-runtime/6.0.0.SNAPSHOT] osgi.identity;
> osgi.identity=org.opendaylight.mdsal.binding-runtime-osgi; type=osgi.bundle;
> version="[6.0.0.SNAPSHOT,6.0.0.SNAPSHOT]"; resolution:=mandatory [caused by:
> Unable to resolve org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT:
> missing requirement
> [org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT] osgi.service;
> filter:="(objectClass=org.osgi.service.component.ComponentFactory)";
> effective:=active]
> at
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> ... 12 more
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to
> resolve org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT: missing
> requirement [org.opendaylight.mdsal.binding-runtime-osgi/6.0.0.SNAPSHOT]
> osgi.service;
> filter:="(objectClass=org.osgi.service.component.ComponentFactory)";
> effective:=active
> at
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> ... 13 more
> {noformat}
> Adding above _dsannotations-options supresses the manifest entry and
> everything works as expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
