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:[email protected]]
> > Sent: Tuesday, August 14, 2018 6:38 PM
> > To: [email protected]
> > 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/src/
> > test/jav
> > a/org/apache/sling/resourceresolver/impl/providers/ResourceProvider
> > TrackerT
> > est.java#L210
> > 
> > 
> 
> 


Reply via email to