i'm in general +1 on declaring these "delating" methods in AbstractResource as final, but have some remarks:
1. doing this would fource us to raise the package version to 3.0.0, breaking all bundles relying on 2.x unless we provide and implementation for the old package version as well. 2. it's possible to implement the Resource interface without using AbstractResource - in this case it still could be possible to provide wrong/derivating implementations. so maybe a better solution would be to move the implementations to the interface itself - with Java 8 we can use default implementations and declare them as final as well. but i assume this as well will lead to a major version increase. stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:[email protected]] >Sent: Sunday, August 19, 2018 6:19 PM >To: Sling Developers >Subject: [API] Resource traversal vs Resource Resolver traversal > >Hi, > >we've currently two APIs for resource traversal, the Resource interface >allows to get the parent, list children etc., and the same methods are >part of the resource resolver interface. In fact we have a third variant >using ResourceUtil. > >Now actually, all of these should return the same results. As the >resource resolver implementation is the source of truth, the resource >implementations should delegate to the resource resolver for all these >methods. > >Unfortunately, not all of them do. Will the AbstractResource class does >so, sub classes sometimes override the traversal methods and take >shortcuts. However by taking these shortcuts, the result might differ >from the resource resolver equivalents. For example resource decorators >might not be called, children from different providers might not be >merged etc. > >To fix this problem we should probably declare those methods in >AbstractResource as final. This forces all implementations to use those >implementations. We would also need to fix the NonExistingResource >implementation in the API package, but that's easy to do. > >However, this most likely will break some of the existing >implementations. So we would need to update all resource provider >implementations as well. It's not a big deal as we only have a couple of >them, but still it's not nice. > >On the other hand, simply trusting that every implementation does it >right, does not work as we see now here and there. > >Thoughts? > >Regards >Carsten >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected]
