I think the test is wrong - the API of the ResourceProvider states that if there is more than one provider with the same root path, the one with the highest service ranking is used.
As both providers are registered with the same bundle id, the one registered first has the lower service id and therefore, it should one. I think we should change the test to explicitely use service ranking and register the second one with a higher ranking. Regards Carsten Robert Munteanu wrote > ... or maybe the test is correct and the implementation wrong? In which > case we should adjust the code to make sure that newer service > references are preferred. > > Robert > > > On Wed, 2018-08-15 at 16:22 +0200, Robert Munteanu wrote: >> Thanks for the analysis Stefan, I was able to to follow the code and >> that explains the behaviour change. >> >> My opinion on this is that the test is incorrect and that we should >> remove that part. >> >> Carsten, you wrote that test - maybe on have another opinion? >> >> Thanks, >> >> Robert >> >> On Wed, 2018-08-15 at 08:48 +0000, Stefan Seifert wrote: >>> i've created a branch with some cleanup of the unit tests and >>> updating the osgi-mock dependency - but the problem itself is not >>> solved, but i can explain it >>> >> >> > https://github.com/apache/sling-org-apache-sling-resourceresolver/tree/feature/update-testing-deps >>> >>> - the testReactivation test registers two resource providers with >>> the >>> same path "/", and expects that the 2nd one overlays the 1st one. >>> but >>> this does no longer happen with the latest osgi-mock version. >>> >>> - the reason is that in the old version that was used the >>> comparable >>> implementation of ServiceRanking was wrong - this was fixed in >>> SLING- >>> 5462 >>> >>> - the comparable implementation of ResourceProviderInfo, to which >>> the >>> comparable implementation of ResourceProviderHandler delegates to, >>> relies on comparing the service references if the path is identical >>> >>> - thus with the new (and correct) logic of osgi-mock an overlaying >>> of >>> resource providers is not possible - and it was never possible >>> outside the old osgi-mock context with the broken service reference >>> comparable implementation. >>> >>> the question is: if the test assumption is correct, the code is >>> wrong >>> and has to be changed to make overlay possible. >>> on the other side is this code productive for a long time - maybe >>> the >>> test assumption is false? >>> >>> stefan >>> >>> >>>> -----Original Message----- >>>> From: Robert Munteanu [mailto:romb...@apache.org] >>>> Sent: Tuesday, August 14, 2018 6:38 PM >>>> To: dev@sling.apache.org >>>> Subject: ResourceProviderTrackerTest#testReactivation fails after >>>> updating >>>> to osgi-mock 2 >>>> >>>> Hi, >>>> >>>> I am trying to update the resourceresolver module from 1.4.0 to >>>> 2.3.10 >>>> to fix some failures in configuring components that are needed by >>>> the >>>> ResourceResolver. >>>> >>>> However, this makes the >>>> ResourceProviderTrackerTest#testReactivation fail, at line 210 >>>> [1]. >>>> >>>> Since I'm not familiar with neither the test nor the OSGi mocks >>>> code, I >>>> would welcome another pair of eyes to either clarify what has >>>> changed >>>> in the OSGi mocks or to pinpoint what expectation of the test is >>>> not >>>> met. >>>> >>>> Thanks, >>>> >>>> Robert >>>> >>>> [1]: https://github.com/apache/sling-org-apache-sling- >>>> resourceresolver/blob/85c19139cfe5f174b65b2daf3791bc4af650ce1b/sr >>>> c/ >>>> test/jav >>>> a/org/apache/sling/resourceresolver/impl/providers/ResourceProvid >>>> er >>>> TrackerT >>>> est.java#L210 >>>> >>>> >>> >>> >> >> > > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
