[Geoserver-devel] [jira] (GEOS-5931) GeoServerDataDirectory.findFile shouldn't force to return a File when not-dealing with an actual file.

GeoServer GeoServer Developer
1

Daniele Romagnoli created ImprovementGEOS-5931
GeoServerDataDirectory.findFile shouldn’t force to return a File when not-dealing with an actual file.

Issue Type:

ImprovementImprovement

Affects Versions:

2.3.4, 2.4-beta

Assignee:

Andrea Aime

Created:

26/Jul/13 3:52 AM

Description:

ResourcePool.getGridCoverageReader always tries to find a File from the coverageStore url String when the reader is null.
It uses GeoserverDataDirectory.findDataFile utility method which always return a File on top of that String.

There are some cases (as an instance, for custom plugins like ArcSDE or PGRaster automatic configuration I’m working on) where the url is something like this:

sde://user:pass@anonymised.com:port/instance

or

pgraster://user:pass@anonymised.com:port:db.schema…@anonymised.com

In those cases it would be surely bettere if we don’t force the URL to be converted to a File and let it as a String so that the underlying GridCoverageReader will know how to properly parse that String.
Also note that, on Windows, doing a new File(String url) may transform
sde://user into sde:\user and pgraster://user into pgraster:\ which won’t allow proper parsing anymore, having changed the prefix syntax.

For this reason, I think it would be better if GeoserverDataDirectory.findDataFile returns a File from a String only in case that file really exist; returning null otherwise.
By this way, ResourcePool.getGridCoverageReader may decide whether to pass down to the GridCoverageReader, the returned file (if any) or the url String as is.

I was thinking if instead of changing the ImageMosaicJDBC code to try to parse Files having similar strange path (pgraster://something), we could relax somehow this “force to be a File” behaviour on ResourcePool…
We could probably modify the findDataFile to return a File only in case it really deals with a file:
(file:/ + file: + /some/path/to/something + c:/ + …) and skip “peculiar” cases like:
myformat://customSyntax.

We can probably think about returning null (as a File, to continue passing down a string) in case we see a “something://” prefix longer than a certain amount of chars (to make sure that C:/ still work)… (Do we risk by this way to improperly parse some peculiar network mapping / protocol I’m unaware of?)

What are your thoughts on this topic?
Please, let me know.
Best Regards,
Daniele

Project:

GeoServer

Priority:

MinorMinor

Reporter:

Daniele Romagnoli
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: [http://www.atlassian.com/software/jira](http://www.atlassian.com/software/jira)