Jody,
My apologies if I sound or have sounded agitated in this discussion. I
do hope we find a solution.
Thanks for the analysis I believe we are now working on the same
problem: clarifying api design
Yes, I share your goal but we don't seem to find a way to agree? I have
done a proposal for
Niels:
Thanks for the analysis I believe we are now working on the same problem:
clarifying api design
org.geosever.platform.resource.Files and
org.geoserver.platform.resource.Paths are not strictly a ResourceStore
utility class. These classes helped the GeoServer codebase adjust to having
Resou
Niels:
The ResourceStore API should only use relative paths.
The test case is problematic and in error.
Removing leading slashes from resource store paths was already done.
--
Jody Garnett
On Aug 2, 2023 at 11:14:54 PM, Niels Charlier wrote:
> Hello Jody,
>
> You write "I am suggesting path
Jody,
Note that the current javadoc oforg.geoserver.platform.resource.Files is
highly problematic.
From the original javadoc we get:
"Utility class for handling Resource paths in a consistent fashion.
This utility class is primarily aimed at implementations of
ResourceStore "
This uti
Jody,
Perhaps I can offer a suggestion that may be considered a reasonable
compromise.
The "resource:" URLs are not used because they were never documented in
user docs. (The javadoc however clearly states that it always was the
intention to be used for access to the 'data directory' via URL
Hello Jody,
You write "I am suggesting paths that return true for this method be not
allowed to access resources from the resource store. "
I think this is problematic: the method is OS dependent: a path with
leading slash will return "false" on windows and "true" on linux. So
your suggestio
Niels:
Comments inline
--
Jody Garnett
On Aug 2, 2023 at 12:20:43 PM, Niels Charlier wrote:
> Hi Jody,
>
> I do support checking everything is handled correctly.
>
Thanks Niels, sorry I am a bit frustrated these days so am probably not
explaining clearly.
I just don't seem the point in brea
Hi Jody,
I do support checking everything is handled correctly.
I just don't seem the point in breaking huge amounts of code for
nothing. And that is what will happen if we start throwing exceptions in
the resource store if the path starts with a "/". Which is actually
normal, because the res
Niels:
We may be on the same page, you indicate ResoueceStore should never use
absolute paths for the file system.
That is the decision I wish to make, and then we should go do the work to
enforce it. How much work? I am not sure, hence the work party.
There is something subtle here though. You
Hello Jody,
Unfortunately I am not really on board with your plan. I really don't
think we need to make a new branch and do a lot of work. This seems like
a lot of unnecessary work. I think the original design is fine, and does
not require breaking the code base. We just need to go back to how
10 matches
Mail list logo
