Bart Thierens created SLING-12413:
-------------------------------------
Summary: OSGi mocks ranked service collections are not ordered
consistently
Key: SLING-12413
URL: https://issues.apache.org/jira/browse/SLING-12413
Project: Sling
Issue Type: Bug
Components: Testing
Affects Versions: Testing OSGi Mock 3.5.0
Reporter: Bart Thierens
The OSGi mocks rank services by service.ranking to simulate Felix workings, see
[here|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blame/2caaa14f5c38a54a0239f0f5550cd8a432307304/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java#L710]
This works fine when you register the components before the calling/using
component (=the one that holds the reference to the collection of other
components) is registered itself.
The OSGiServiceUtil finds all matching services, sorts the collection of
references and then proceeds to inject the actual impl's in that order.
However, if you register your calling component first - or you add more
components after the calling component was already registered - they will just
be added as-is to the collection. This is done
[here|https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blame/2caaa14f5c38a54a0239f0f5550cd8a432307304/core/src/main/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtil.java#L863].
In Felix this works correctly and the collection is always sorted correctly,
even after late add's or remove's of references.
This causes inconsistent behaviour while testing. See
[this|https://github.com/senn/aemcontext-no-serviceranking-ordering/blob/incorrect-ordering-depending-on-injection-time/src/test/java/com/github/senn/services/InjectionTimeOrderingTest.java]
test example I prepared. It has 3 tests:
* 1 one where the references are registered first - OK
* 1 one where the calling service is registered first -
{color:#FF0000}NOK{color}
* 1 combination test - {color:#FF0000}NOK{color}
I know the OSGi spec does not really define the ordering but if you do it 'the
Felix way' in once place, it should at least be consistent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
