Perfect, thanks Carsten and Stefan for looking into this!

Robert

On Fri, 2018-08-17 at 07:50 +0000, Stefan Seifert wrote:
> ok - i've fixed the unit test accordingly and merged my branch.
> 
> stefan
> 
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:[email protected]]
> > Sent: Friday, August 17, 2018 7:42 AM
> > To: [email protected]; 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:[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/85c19139cfe5f174b65b2daf3791bc4af650c
> > > > > > e1b/sr
> > > > > > c/
> > > > > > test/jav
> > > > > > a/org/apache/sling/resourceresolver/impl/providers/Resource
> > > > > > Provid
> > > > > > er
> > > > > > TrackerT
> > > > > > est.java#L210
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > [email protected]
> 
> 


Reply via email to