kwin commented on a change in pull request #10:
URL:
https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/pull/10#discussion_r750187560
##########
File path:
core/src/test/java/org/apache/sling/testing/mock/osgi/OsgiServiceUtilTest.java
##########
@@ -100,7 +100,6 @@ public void testService3() {
List<Map<String, Object>> reference3Configs =
service3.getReference3Configs();
assertEquals(1, reference3Configs.size());
- assertEquals(200,
reference3Configs.get(0).get(Constants.SERVICE_RANKING));
Review comment:
> so i'm wondering if it would do harm if we keep it as it was before -
applying the DS magic everywhere, even if only BundleContext.registerService is
called.
Yes, that may cause harm as then the mock testing may succeed because it
considers OSGi metadata but real code does not work because it uses
BundleContext.registerService(). Just consider the use case where you use
dynamic service registration and you rely on the service.ranking. But instead
of passing it explicitly as property to BundleContext.registerService you
incorrectly rely on DS metadata. Also the other way around is possible, e.g.
test code fails, because it relies incorrectly on DS/metatype metadata while on
real OSGi container the properties are not set and therefore use a different
behaviour (maybe a bit artificial but still possible).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
