Hi guys,
I didn't receive any feedback on this.
I have encountered again the issue on windows which converts my
"pgraster://" string into a "pgraster:\ file" which let fail my URL parsing
code.
I would like to do something like this on that utility method.
The last else in GeoserverDataDirectory.findDataFileFile simply returns new
File(path).
I would do instead something like this:
File file = new File(path);
if (file.exists()) {
return file;
}
return null;
Afterwards in the ResourcePool code (near to line 1244):
final File obj = GeoserverDataDirectory.findDataFile(info.getURL());
reader = gridFormat.getReader(obj, new Hints(hints));
if obj is null, I will use the original info.getURL() String instead of obj
as input of the getReader.
What do you think about it?
Cheers,
Daniele
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Daniele Romagnoli
Senior Software Engineer
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Thu, Jul 18, 2013 at 3:59 PM, Daniele Romagnoli <
[email protected]> wrote:
> Hi List,
> I'm working on simplifying a bit the steps needed to configure an
> ImageMosaicJDBC based on PGRaster.
> http://jira.codehaus.org/browse/GEOT-4507
>
> Right now, I'm playing with Wicket in order to allow specifying
> configuration parameters from the GUI (PG server, port, pguser, databaset,
> ...) so that it can be passed down to the AbstractGridFormatReader as a
> special URL.
> something like: pgraster://user:pass@server
> :port:database.schema.table.....
>
> I have voted for this approach since while looking for examples, I have
> seen that the ArcSDE store panel does something similar.
> sde://user:pass@server:port/instance
>
> When doing some tests right now, I have noticed that the ResourcePool
> always converts the coverageStore url String to a File (by using the
> GeoserverDataDirectory.findDataFile utility method).
>
> I'm not sure about how this allows the sde://user:pass@server:port/instance
> String url to be interpreted as a File (I didin't check the arcSde store
> code).
>
> 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
>
>
>
>
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
> Ing. Daniele Romagnoli
> Senior Software Engineer
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
