Thanks Niels:
I admit to being very sensitive about PropertyDataStore as its original goal is
as a teaching aid for new GeoTools developers. As such I want it to be a very
clear example, with few workarounds.
I actually have a property-ng DataStore in the wings (based on ContentDataStore
foundation). I think I will roll it out into the codebase after GeoTools 10 is
released.
--
Jody Garnett
On Wednesday, 10 July 2013 at 8:23 AM, Niels Charlier wrote:
> Jody,
>
> There is an additional issue. A lot of unit tests use paths with the property
> data store, relative to the start-up directory rather than the data
> directory. We need to avoid having to edit all those tests.
>
> I have found another solution working only from geoserver.
> Justin pointed me to this place:
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L615
>
> So this is what I propose:
> https://github.com/NielsCharlier/geoserver/commit/aec803994b82d2cbaa1d58e1d9f56f1ade2204bb
>
> Atm it is not possible to use the url format in the property data store.
> Allowing this also allows users to use "relative url's", relative to the data
> directory. Relative url's technically do not exist, but they are the standard
> for the other data stores in geoserver. So that is consistent. In fact,
> according to the geoserver documentation this is already possible:
> http://docs.geoserver.org/latest/en/user/data/app-schema/data-stores.html#property-file
> which is not actually the case. So this patch is only making property file
> datastore consistent with its own documentation.
>
> Furthermore, in this solution there is no problem with the unit tests. These
> tests never use url's, and when using the regular path format, relative
> directories are still relative to current directory. Problem solved.
>
> Justin, what do you think?
>
> Cheers
> Niels
>
> On 10/07/13 00:03, Jody Garnett wrote:
> > Hi Niels:
> >
> > Well what you describe is a valid use case, and worth adding to GeoTools
> > (just in a way that does not break the Factory).
> >
> > The easiest thing I can think of is to make:
> >
> > final File base;
> >
> > And to set it to the current directory in the no-argument constructor (use
> > by FactoryFinder), and to set it in the constructor for use by GeoServer?
> >
> > If you like I can bash up a patch, and this is the week to do it before the
> > API freeze hits for winter (in Australia).
> > --
> > Jody Garnett
> >
> >
> > On Wednesday, 10 July 2013 at 12:36 AM, Niels Charlier wrote:
> >
> > > Hello Jody,
> > >
> > > Thank you for the reviewing the code.
> > >
> > > The issue came from setting up a data directory for the csw cite tests
> > > using property files. I found that there was no way to set up the data
> > > configuration using a relative path to refer to the directory with
> > > properties files.
> > >
> > > I admit I simply (and quite lazily) copied the behaviour of the h2 data
> > > store, where this does work. I will now check a scenario where we use
> > > resourcepool instead.
> > >
> > > Cheers
> > > Niels
> > >
> > > On 09/07/13 06:00, Jody Garnett 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?
> > > >
> > > > --
> > > > Jody Garnett
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------------------
> > > > 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 GeoTools-Devel@lists.sourceforge.net
> > > > (mailto:GeoTools-Devel@lists.sourceforge.net)
> > > > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> > > ------------------------------------------------------------------------------
> > >
> > > 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
> > > GeoTools-Devel@lists.sourceforge.net
> > > (mailto:GeoTools-Devel@lists.sourceforge.net)
> > > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> > >
> > >
> > >
> >
> >
>
------------------------------------------------------------------------------
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
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
