sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Munteanu <romb...@apache.org>
Subject Re: ResourceProviderTrackerTest#testReactivation fails after updating to osgi-mock 2
Date Wed, 15 Aug 2018 14:26:10 GMT
... 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:rombert@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
> > > 
> > > 
> > 
> > 
> 
> 



Mime
View raw message