ok - i've fixed the unit test accordingly and merged my branch. stefan
>-----Original Message----- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Friday, August 17, 2018 7:42 AM >To: dev@sling.apache.org; Robert Munteanu >Subject: Re: ResourceProviderTrackerTest#testReactivation fails after >updating to osgi-mock 2 > >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
