Hello Jody and Gabriel,
Sorry for my late response. I have a suggestion to resolve the issue,
please let me know what you think,
My suggestion is that I would make a pull request with the following
proposed changes, and you would review it.
1. The methods Resources.fromPath as well as Resources.fromURL with a
"file:" URL follow your guidelines: relative paths are interpreted as
resource store paths, absolute paths are interpreted as file system
paths. However, I suggest that a relative "file:" URL produces a warning
message that says that relative "file:" URLs are deprecated and that one
should use a "resource:" URL instead.
2. The resource store implementation is separate from the two methods as
specified above, and only provides access to files that are either in
the data directory (file system resource store) or part of an external
emulation of a file/folder hierarchy (such as jdbc database for the jdbc
resource store). It has its own "root", and therefore the
ResourceStore.get(...) method returns the same result with or without
leading slash. A unit tests should check that the store does not provide
any access to absolute paths on the file system. Javadoc should explain
that Resources.fromPath or Resources.fromURL should be used for access
to paths and URLs in general, and that direct usage of the resource
store is only for access to configuration files and directories with a
hard coded location (relative to the 'data directory').
3. The Paths class javadoc is fixed or the class is refactored so that
there is a clear distinction between resource store paths and file paths.
4. A page is added to the developer guide that specifies the above
guidelines as well as general guidelines on how geoserver developers
should deal with resources, URLs, files, etc. so that the generic nature
of the resource store API is preserved in the future.
I look forward to your feedback.
Kind Regards
Niels
On 18/08/2023 17:35, Jody Garnett wrote:
Niels:
I checked if we were having a work party today, and put a little time
into the activity.
And I finally have a useful answer for you: Why did Resource absolute
path change from being relative to the data directory?
The answer is ... the concept of a Path was used all over our
codebase, with different conversions happening, especially around
absolute paths. This caused problems with a Java 11 change for windows
which revealed how many different conventions we had in the codebase.
So something had to change - paths was made consistent - so if you
stopped with in a debugger, at any point, and saw a "path" you could
have confidence in what it means.
To that end a relative path (anywhere in the codebase) is now relative
to the data directory location.
There is a little bit of code in the REST Resource API that is
forgiving for external scripts that use an absolute path. But it is
changed to be consistent (ie relative path) as soon as possible.
If you find any other special cases we can make note of them.
--
Jody Garnett
--
--
Jody Garnett
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
