org.osgi.test.cases.framework test case is not correct

[bjhargrave]

Original bug ID: BZ#3124 From: Georgi Boyvalenkov <georgi.boyvalenkov@bosch-si.com> Reported version: R6

[bjhargrave]

Comment author: Georgi Boyvalenkov <georgi.boyvalenkov@bosch-si.com>

There are two wrong assertions:

1. testDynamicImportPackage Wrong assert in BundleWiringTests at line 960:

checkBundleWire((BundleWire)tb3Wiring.getRequiredWires("osgi.wiring.package").get(1), tb2Wiring, tb3Wiring, bc, (BundleRequirement)tb3Wiring.getRequirements("osgi.wiring.package").get(0));

Must compare either the first wire with first requirement or the second wire with second requirement.

2. testOSGiEE

Test bundle resolver.tb10.v130 has header Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.4)))", which can be resolved by JavaSE 1.4, but test case incorrectly expects this bundle could not be resolved.

[bjhargrave]

Comment author: @tjwatson

What version of the CT is this, it does not look like the latest R7 or even R6 version? Can you check if this bug exists in the latest code in the git repository?

The structure is largely the same though, but we moved to using constants for namespaces and removed unnecessary casting.

(In reply to Georgi Boyvalenkov from comment BZ#0)

There are two wrong assertions:

1. testDynamicImportPackage Wrong assert in BundleWiringTests at line 960:

checkBundleWire((BundleWire)tb3Wiring.getRequiredWires("osgi.wiring. package").get(1), tb2Wiring, tb3Wiring, bc, (BundleRequirement)tb3Wiring.getRequirements("osgi.wiring.package").get(0));

Must compare either the first wire with first requirement or the second wire with second requirement.

I don't understand what you mean by second requirement with the "osgi.wiring.package" namespace here. That bundle in question, tb3 which corresponds to "wiring.tb5.jar", only has a single "osgi.wiring.package" requirement with:

DynamicImport-Package: *

That translates into a single requirement that looks something like this:

osgi.wiring.package; filter:="(osgi.wiring.package=*)"; cardinality:=multiple

That single requirement will get wired to each dynamically resolved package at runtime and the test correctly validates that the first and only requirement in the osgi.wiring.package namespace is wired to three packages because the test attempts to load three different packages using the bundle.

2. testOSGiEE

Test bundle resolver.tb10.v130 has header Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.4)))", which can be resolved by JavaSE 1.4, but test case incorrectly expects this bundle could not be resolved.

Again, not sure what version of the CT you are running. The latest has this note which was added in 2010: // Note that this test assumes the tests are run on a JavaSE 1.5 vm or higher

You mention JavaSE 1.4, are you attempting to run on JavaSE 1.4? This particular bundle must not resolve on JavaSE 1.5+ and the testcase assumes you are running on JavaSE 1.5+.

Note that I do think this test has issues running on Java 9+ (see bug BZ#3122).

[bjhargrave]

Comment author: Georgi Boyvalenkov <georgi.boyvalenkov@bosch-si.com>

I am using R6 CT. For the dynamic import issue, the problem is that multiple cardinality is not supported for package wiring, so a requirement is created for each dynamically wired package. It will be fixed if it breaks the specification. For the execution environment problem, we assume that specific JDK version implies that lower(and backward compatible) JDK versions are also provided as capabilities(in order to resolve bundles, depending on them). So when we are running tests on JDK 1.8, all previous versions are also provided.

[bjhargrave]

Comment author: @bjhargrave

(In reply to Georgi Boyvalenkov from comment BZ#2)

I am using R6 CT.

R7 is the latest released CT version. R8 is currently in development, So we can make fixes to R8 for issues on the current source code base. But we cannot fix the R6 CT.

(In reply to Georgi Boyvalenkov from comment BZ#2)

For the execution environment problem, we assume that specific JDK version implies that lower(and backward compatible) JDK versions are also provided as capabilities(in order to resolve bundles, depending on them).

The CT is only meant to be run on the JRE for which is was designed. For example, the CT may not work on the JRE which is used on an actual production device.

[bjhargrave]

Comment author: @tjwatson

(In reply to Georgi Boyvalenkov from comment BZ#2)

I am using R6 CT. For the dynamic import issue, the problem is that multiple cardinality is not supported for package wiring, so a requirement is created for each dynamically wired package. It will be fixed if it breaks the specification.

See https://osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.namespace.PackageNamespacehttps://osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.namespace.PackageNamespace

Particularly the bullet on cardinality:

The cardinality directive has limited applicability to this namespace. A cardinality directive specified on the Import-Package or DynamicImport-Package headers must be ignored. Only requirements with resolution set to dynamic and the package name contains a wildcard must have the cardinality directive set to multiple. Otherwise, a cardinality directive must not be present in a requirement.

For the execution environment problem, we assume that specific JDK version implies that lower(and backward compatible) JDK versions are also provided as capabilities(in order to resolve bundles, depending on them). So when we are running tests on JDK 1.8, all previous versions are also provided.

See https://osgi.org/specification/osgi.core/7.0.0/framework.namespaces.html#framework.namespaces.osgi.ee

The framework should provide a single capability for each osgi.ee name (e.g. JavaSE) and should have a List attribute for all the versions the running JRE is compatible with. So for JavaSE 1.8 that would be:

osgi.ee;
    osgi.ee="JavaSE";
    version:List<Version>="1.2,1.3,1.4,1.5,1.6,1.7,1.8"

The filter (&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.4))) must not match such a capability because the values 1.6, 1.7, 1.8 all make (!(version>=1.4)) evaluate to false. I suspect you are providing each version as a separate osgi.ee capability which would be incorrect.

[bjhargrave]

Comment author: Georgi Boyvalenkov <georgi.boyvalenkov@bosch-si.com>

(In reply to Thomas Watson from comment BZ#4)

For the execution environment problem, we assume that specific JDK version implies that lower(and backward compatible) JDK versions are also provided as capabilities(in order to resolve bundles, depending on them). So when we are running tests on JDK 1.8, all previous versions are also provided.

See https://osgi.org/specification/osgi.core/7.0.0/framework.namespaces. html#framework.namespaces.osgi.ee

The framework should provide a single capability for each osgi.ee name (e.g. JavaSE) and should have a List attribute for all the versions the running JRE is compatible with. So for JavaSE 1.8 that would be:

osgi.ee;
    osgi.ee="JavaSE";
    version:List<Version>="1.2,1.3,1.4,1.5,1.6,1.7,1.8"

The filter (&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.4))) must not match such a capability because the values 1.6, 1.7, 1.8 all make (!(version>=1.4)) evaluate to false. I suspect you are providing each version as a separate osgi.ee capability which would be incorrect.

Yes, capabilities are provided for each version, this will be revised. Thanks.