You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Wouter Bancken <wo...@aca-it.be> on 2015/07/29 13:16:50 UTC
Resolving fragment bundles in a subsystem with a uses relation
Dear,
We are having an issue trying to resolve fragment bundles in a subsystem.
We created a *subsystem* (esa) with the following content (SUBSYSTEM.MF):
Subsystem-Content:
be.aca.test-service-fragment;type="osgi.fragment";version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="1",
be.aca.test-service;version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="2"
Subsystem-Type:
osgi.subsystem.feature
The *fragment* contains the following import packages:
Fragment-Host:
be.aca.test-service
Import-Package:
be.aca.subsystem.test_service.api;version="[1.0,2)",
be.aca.test-service
The *bundle* contains the following import and export packages:
Export-Package:
be.aca.subsystem.test_service.api;uses:="be.aca.subsystem.test_service.internal";version="1.0.1.SNAPSHOT",
be.aca.subsystem.test_service.internal;version="1.0.1.SNAPSHOT"
be.aca.subsystem.test_component";version="1.0.1.SNAPSHOT"
Import-Package:
be.aca.subsystem.test_component;version="[1.0,2)",
be.aca.subsystem.test_service.api;version="[1.0,2)"
The current Aries implementation is not able to find the capability for the
fragment. The SubsystemResource will first look in the SystemRepository and
next in the LocalRepository. This LocalRepository should be able to find
the fragment but it can not. We tracked this down to
BundleResource.computeOsgiIdentityCapability which calls a constructor of
OsgiIdentityCapability that manually sets the type to osgi-bundle (while it
should be fragment in this case). Therefore the requirement and the
capability do not match because of the different type.
Since the LocalRepository can not find the capability, the Aries
implementation will delegate it to our own custom repository which will
then find the correct capability in the esa. However due to the import and
export statements, our custom repository will also provide the other
packages from the test-service bundle.
Next, it will try to resolve the test-service bundle. As always it will
first look in the SystemRepository and next in the LocalRepository. The
LocalRepository will be able to find the capabilities. At this point, the
following uses constraint violation occurs:
Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint
violation. Unable to resolve resource be.aca.test-service
[jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar]
because it exports package 'be.aca.subsystem.test_service.internal' and is
also exposed to it from resource be.aca.test-service
[/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar]
via the following dependency chain:
be.aca.test-service
[jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar]
import:
(&(osgi.wiring.package=be.aca.subsystem.test_service.api)(&(version>=1.0.0)(!(version>=2.0.0))))
|
export: osgi.wiring.package: be.aca.subsystem.test_service.api;
uses:=be.aca.subsystem.test_service.internal
export: osgi.wiring.package=be.aca.subsystem.test_service.internal
be.aca.test-service
[/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar]
We think that this issue will be resolved if the LocalRepository would be
able to find fragments since the LocalRepository will then be able to
handle all requirements. Our custom repository would never be called.
Is it a known issue that the BundleResource can not distinguish between
bundles and fragments? Or was there a reason to fix the type to "bundle"?
Best regards,
Wouter Bancken
Solution Engineer
Re: Resolving fragment bundles in a subsystem with a uses relation
Posted by Wouter Bancken <wo...@aca-it.be>.
We do not have any export/import packages on the subsystem level. Only
on the level of the fragment and bundle.
To be more specific in our questioning:
Is there any reason (by design) that
BundleResource.computeOsgiIdentityCapability only works for bundles
and not for fragments? Or is this a bug in the Aries implementation?
Best regards,
Wouter Bancken
Solution Engineer
2015-07-29 13:22 GMT+02:00 Kamesh Sampath <ka...@liferay.com>:
>
> IMHO, the subsystem type “osgi.subsystem.feature” is a unscoped subsystem, ideally the Export/Import packages from them will not have any effect.
>
> For “osgi.subsystem.feature” you can play with imports/exports within the respective Subsytem resources instead at the subsystem level.
>
>
>
> On 29/07/15 4:46 pm, "Wouter Bancken" wrote:
>
> Dear,
>
> We are having an issue trying to resolve fragment bundles in a subsystem.
>
> We created a subsystem (esa) with the following content (SUBSYSTEM.MF):
>
> Subsystem-Content:
> be.aca.test-service-fragment;type="osgi.fragment";version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="1",
> be.aca.test-service;version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="2"
>
> Subsystem-Type:
> osgi.subsystem.feature
>
> The fragment contains the following import packages:
>
> Fragment-Host:
> be.aca.test-service
>
> Import-Package:
> be.aca.subsystem.test_service.api;version="[1.0,2)",
> be.aca.test-service
>
> The bundle contains the following import and export packages:
>
> Export-Package:
> be.aca.subsystem.test_service.api;uses:="be.aca.subsystem.test_service.internal";version="1.0.1.SNAPSHOT",
> be.aca.subsystem.test_service.internal;version="1.0.1.SNAPSHOT"
> be.aca.subsystem.test_component";version="1.0.1.SNAPSHOT"
>
> Import-Package:
> be.aca.subsystem.test_component;version="[1.0,2)",
> be.aca.subsystem.test_service.api;version="[1.0,2)"
>
> The current Aries implementation is not able to find the capability for the fragment. The SubsystemResource will first look in the SystemRepository and next in the LocalRepository. This LocalRepository should be able to find the fragment but it can not. We tracked this down to BundleResource.computeOsgiIdentityCapability which calls a constructor of OsgiIdentityCapability that manually sets the type to osgi-bundle (while it should be fragment in this case). Therefore the requirement and the capability do not match because of the different type.
>
> Since the LocalRepository can not find the capability, the Aries implementation will delegate it to our own custom repository which will then find the correct capability in the esa. However due to the import and export statements, our custom repository will also provide the other packages from the test-service bundle.
>
> Next, it will try to resolve the test-service bundle. As always it will first look in the SystemRepository and next in the LocalRepository. The LocalRepository will be able to find the capabilities. At this point, the following uses constraint violation occurs:
>
> Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource be.aca.test-service [jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar] because it exports package 'be.aca.subsystem.test_service.internal' and is also exposed to it from resource be.aca.test-service [/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar] via the following dependency chain:
>
> be.aca.test-service [jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar]
> import: (&(osgi.wiring.package=be.aca.subsystem.test_service.api)(&(version>=1.0.0)(!(version>=2.0.0))))
> |
> export: osgi.wiring.package: be.aca.subsystem.test_service.api; uses:=be.aca.subsystem.test_service.internal
> export: osgi.wiring.package=be.aca.subsystem.test_service.internal
> be.aca.test-service [/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar]
>
> We think that this issue will be resolved if the LocalRepository would be able to find fragments since the LocalRepository will then be able to handle all requirements. Our custom repository would never be called.
>
> Is it a known issue that the BundleResource can not distinguish between bundles and fragments? Or was there a reason to fix the type to "bundle"?
>
> Best regards,
>
> Wouter Bancken
> Solution Engineer
Re: Resolving fragment bundles in a subsystem with a uses relation
Posted by Kamesh Sampath <ka...@liferay.com>.
IMHO, the subsystem type “osgi.subsystem.feature” is a unscoped subsystem, ideally the Export/Import packages from them will not have any effect.
For “osgi.subsystem.feature” you can play with imports/exports within the respective Subsytem resources instead at the subsystem level.
On 29/07/15 4:46 pm, "Wouter Bancken" wrote:
Dear,
We are having an issue trying to resolve fragment bundles in a subsystem.
We created a subsystem (esa) with the following content (SUBSYSTEM.MF):
Subsystem-Content:
be.aca.test-service-fragment;type="osgi.fragment";version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="1",
be.aca.test-service;version="[1.0.1.SNAPSHOT,1.0.1.SNAPSHOT]";start-order:="2"
Subsystem-Type:
osgi.subsystem.feature
The fragment contains the following import packages:
Fragment-Host:
be.aca.test-service
Import-Package:
be.aca.subsystem.test_service.api;version="[1.0,2)",
be.aca.test-service
The bundle contains the following import and export packages:
Export-Package:
be.aca.subsystem.test_service.api;uses:="be.aca.subsystem.test_service.internal";version="1.0.1.SNAPSHOT",
be.aca.subsystem.test_service.internal;version="1.0.1.SNAPSHOT"
be.aca.subsystem.test_component";version="1.0.1.SNAPSHOT"
Import-Package:
be.aca.subsystem.test_component;version="[1.0,2)",
be.aca.subsystem.test_service.api;version="[1.0,2)"
The current Aries implementation is not able to find the capability for the fragment. The SubsystemResource will first look in the SystemRepository and next in the LocalRepository. This LocalRepository should be able to find the fragment but it can not. We tracked this down to BundleResource.computeOsgiIdentityCapability which calls a constructor of OsgiIdentityCapability that manually sets the type to osgi-bundle (while it should be fragment in this case). Therefore the requirement and the capability do not match because of the different type.
Since the LocalRepository can not find the capability, the Aries implementation will delegate it to our own custom repository which will then find the correct capability in the esa. However due to the import and export statements, our custom repository will also provide the other packages from the test-service bundle.
Next, it will try to resolve the test-service bundle. As always it will first look in the SystemRepository and next in the LocalRepository. The LocalRepository will be able to find the capabilities. At this point, the following uses constraint violation occurs:
Caused by: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource be.aca.test-service [jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar] because it exports package 'be.aca.subsystem.test_service.internal' and is also exposed to it from resource be.aca.test-service [/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar] via the following dependency chain:
be.aca.test-service [jar:file:/Users/wouter/Projects/common/osgi-subsystem-support/runner/directory-repository/test-service-fragment-subsystem-1.0.1-SNAPSHOT.esa!/test-service-1.0.1-SNAPSHOT.jar]
import: (&(osgi.wiring.package=be.aca.subsystem.test_service.api)(&(version>=1.0.0)(!(version>=2.0.0))))
|
export: osgi.wiring.package: be.aca.subsystem.test_service.api; uses:=be.aca.subsystem.test_service.internal
export: osgi.wiring.package=be.aca.subsystem.test_service.internal
be.aca.test-service [/var/folders/25/w0q5j_mn4l1771mbxtg6yhhm0000gn/T/inputStreamExtract3569880077784275121.zip/test-service-1.0.1-SNAPSHOT.jar]
We think that this issue will be resolved if the LocalRepository would be able to find fragments since the LocalRepository will then be able to handle all requirements. Our custom repository would never be called.
Is it a known issue that the BundleResource can not distinguish between bundles and fragments? Or was there a reason to fix the type to "bundle"?
Best regards,
Wouter Bancken
Solution Engineer