On Tue, Jul 9, 2013 at 6:26 AM, Andrea Aime <[email protected]>wrote:
> On Tue, Jul 9, 2013 at 6:00 AM, Jody Garnett <[email protected]>wrote:
>
>> I have been having an interesting time reviewing a recent pull request
>> for PropertyDataStore:
>> - https://github.com/geotools/geotools/pull/221
>>
>> The concept introduces the idea of a base directory (apparently shared
>> with HT DataStore .. and others?). Rough idea is to provide a geotools
>> specific alternative to the current directory when interpreting relative
>> paths. I assume the motivation comes from wanting to easily find stuff in
>> the
>> GeoServer data directory.
>>
>> I have a couple of ideas on how to proceed, but I wanted to start a
>> discussion here to ensure I understand the issue correctly?
>>
>
> I'm a bit confused myself. GeoServer already has support for manipulating
> a relative file path
> (e.g., file:/data/shapefiles/states.shp) into an absolute reference to the
> specific file prior to passing the
> urls to the store.
>
I think it is because the data store doesn't expose the "magic parameter",
which I believe has to be named "url". To fix that we would have to either
change the data store parameters or amend the hack in geoserver that
recognizes relative file based urls and include the directory parameter.
Seemed like less work to use the geoserver specific initializer extension
point but we can investigate how hairy these other options might be.
For H2 i don't think it will be as easy since the parameter isn't exposed
as a file/url.
>
> Wondering why this is not working for directory data store, and whether it
> could be amended to work,
> so that factories do not need to become stateful (the factories should be
> managed by the factory
> registry, which can pretty much do as it likes it terms of caching them,
> releasing them, and so on)
>
Agreed keeping factories stateless is better but we also have to keep in
mind those that make direct use of the factory which is a quite common case
afaik. Being able to maintain some state there is nicer from an api pov
than having to use hints or parameters.
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> 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
> _______________________________________________
> GeoTools-Devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
