[
https://issues.apache.org/jira/browse/SLING-12385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868884#comment-17868884
]
Henry Kuijpers commented on SLING-12385:
----------------------------------------
[~bartthierens] I provided a fix PR for your develop branch :) :
[https://github.com/senn/aemcontext-no-serviceranking-ordering/pull/1/files]
Basically, when calling "registerService", you don't take into consideration
the SCR metadata that is available for the services. This makes, indeed, your
"service.ranking"-property get ignored.
In the very last example, you tried to register a service with properties
called "service.ranking:Integer" - However, the ":Integer"-suffix is just
syntax for the configuration files, to make them not become a string. Not for
OsgiContext. In OsgiContext, you need to provide a "service.ranking"-property
with a value of type integer. When creating configurations, ".cfg.json" is nice
to use, as you can then provide the value without quotes, as a number, which
then automatically becomes an integer.
> OSGi mock context seems to not take service ranking into account
> ----------------------------------------------------------------
>
> Key: SLING-12385
> URL: https://issues.apache.org/jira/browse/SLING-12385
> Project: Sling
> Issue Type: Bug
> Components: Testing
> Affects Versions: Testing OSGi Mock 3.4.2
> Reporter: Bart Thierens
> Priority: Major
>
> Logging this issue here as I can't log it in github. I assume this is the
> correct approach.
> I am unable to make my registered services in a test case mimick the same
> ordering behaviour than in an actual OSGi environment. The
> AemContext/AemContextImpl/SlingContextImpl/OsgiContextImpl does not respect
> the `@ServiceRanking` annotation, nor the component property
> "service.ranking".
> It seems vital to be able to test that a certain part of application logic
> executes certain services in order, and that seems impossible now - unless
> the developer registers the services exactly in the order he expects them,
> which beats the purpose of the test.
> If this is documented behaviour, I can't find it anywhere... (And it's still
> not correct imho)
> Personal use case: A certain component that has "processors" (which are
> components implementing a single service) that are ordered by service ranking
> (low = first, high = later). When a service is disabled/unregistered,
> registered or even re-registered, the order must stay consistent (low =>
> high). This actually works perfectly, but not in test-cases.
> I created a demo (AEM) project that showcases this problem:
> [https://github.com/senn/aemcontext-no-serviceranking-ordering]
> It contains tests for the various context implementations and also a separate
> branch that has the same issue without `@ServiceRanking` and with the
> "service.ranking" properties.
> I don't have a fix ready, but might look into it in a few weeks when I have
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
