Hello Niels, The PRs for this activity contain extensive discussion.
The fundamental issue was the handling of absolute paths which was done differently by different sections of code. Specifically we found that the REST API endpoint was allowing paths *//data* and */data *to both reference content in the data directory, rather than treating the first one as an absolute path. In response we tightened up the javadocs and added test cases including the one you mentioned. I agree that this goes against the goal of resource store, but the codebase had drifted away from the intended use over time. Now that you are present in the discussion it would be a good opportunity to discuss this with the parties involved. -- Jody Garnett On Jul 3, 2023 at 2:50:02 PM, Niels Charlier <ni...@scitus.be> wrote: > Hello Jody and others, > > I am having trouble understanding the changes that were made about 6 > months ago to the ResourceStore's expected behaviour. > > In particular, in the class > 'org.geoserver.platform.resource.ResourceTheoryTest', > the unit test 'theoryRootSlashIsIgnored' was replaced by > 'theoryRootIsAbsolute'. I cannot make sense out of this theory test at all. > > > This seems to be entirely contradictory to the whole reason that the > ResourceStore API was created, that is to make an abstraction of the *Data > Directory*, so that it can be replaced by something else (such as jdbc > store or other implementations that have been made). There was already > support for absolute file paths in all circumstances by using "file:" URLs. > This will bypass the resource store and call Files.asResource instead. But > resource: URLs are for the data directory or alternative resource store > only. How does it make sense to get absolute paths from the resource > store? > > > In order to make jdbc-config pass the tests, I will have to turn off this > particular method. But why should the test even be there if the file > resource store is the only one that could ever support it? Programmers and > users will rely on this behaviour and support for all alternative > implementations of ResourceStore will be broken. In this case we may as > well do away with the API and just use the file system directly again. > > Kind Regards > > Niels >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
