[Geoserver-devel] GSIP 106 - Managed File API update - and voting reminder

If you have not yet had a chance to vote, please take a cup of coffee and have a look at:

If you would just look at the proposed classes:

For a sense of where we are at:

If you would like to see the code:

Progress:

  • GeoServerResourceLoader - search locations now removed
  • GeoServerExtensions.file( path ) - method added to access servletContext for web.xml
  • GeoServerResourceLoader - training wheels now removed, internals now only use Resource
  • GeoServerDataDirectory - file access methods now use Resource
  • GeoServerSecurityManager - file access methods now use Resource

After this first pull request (devoted to file access) there will be a gap as we update each module to use Resource.

Note: The internals of GeoServerResourceLoader, GeoServerDataDirectory and GeoServerSecurityManager are setup to allow “inline refactor” to quickly updated client.

Jody Garnett

+1 - it's taken me a while to get my head around this one but now I understand it, I like it. Would make management between development, test, and production instances of the servers a lot easier with JDBC config.

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.

Thanks Phil,

Even with out JDBC config I am seeing some benefits in simplifying the code, and having a chance for consistent file lock and file watch across our data directory. I suspect someone could have fun with a github backed implementation for example.

···

Jody Garnett

On Tue, Mar 4, 2014 at 7:10 AM, Phil Scadden <p.scadden@anonymised.com> wrote:

+1 - it’s taken me a while to get my head around this one but now I
understand it, I like it. Would make management between development,
test, and production instances of the servers a lot easier with JDBC config.

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+1

Thanks Jody for this cool stuff.

Some stupid questions, apologize but I do not have much time to see deeply the implementation proposal … basically if I understood correctly this resource store write the file into the data dir streamed out from the DB if it does not exist, is that right?

In that case I see that you already spoken and taken into account the locking mechanism.

Please correct me if I’m wrong, as I said I did not have the chance to study the examples.

···

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Alessio Fabiani
@alfa7691
Founder/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 331 6233686

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Mon, Mar 3, 2014 at 9:42 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks Phil,

Even with out JDBC config I am seeing some benefits in simplifying the code, and having a chance for consistent file lock and file watch across our data directory. I suspect someone could have fun with a github backed implementation for example.


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Jody Garnett

On Tue, Mar 4, 2014 at 7:10 AM, Phil Scadden <p.scadden@anonymised.com> wrote:

+1 - it’s taken me a while to get my head around this one but now I
understand it, I like it. Would make management between development,
test, and production instances of the servers a lot easier with JDBC config.

Notice: This email and any attachments are confidential.
If received in error please destroy and immediately notify us.
Do not copy or disclose the contents.


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Some stupid questions, apologize but I do not have much time to see deeply the implementation proposal … basically if I understood correctly this resource store write the file into the data dir streamed out from the DB if it does not exist, is that right?

The proposal is actually just focused on the introduction of the ResourceStore API (since this will involve an application wide refactor similar to when we updated FeatureCollection).

Separately the JDBC Config module is going to implement ResourceStore backed by a database - in the fashion you describe. If the code asks for a file it will be written out to the data directory. If the code only asks for an input stream we may be able to provide that right from the database.

···

In that case I see that you already spoken and taken into account the locking mechanism.

The email discussion has a resulted in a couple additions for the FileSystemResourceStore implementation: file watcher functionality, file lock and “atomic file write”.

Please correct me if I’m wrong, as I said I did not have the chance to study the examples.

I will be looking at file lock and file watching next, so you have not missed anything yet.

I am late to the party on this but +1 from me. I spent some time working with Jody on the approach and design so am familiar with it at a high level. Work is moving along great, good stuff Jody.

···

On Tue, Mar 4, 2014 at 4:06 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Some stupid questions, apologize but I do not have much time to see deeply the implementation proposal … basically if I understood correctly this resource store write the file into the data dir streamed out from the DB if it does not exist, is that right?

The proposal is actually just focused on the introduction of the ResourceStore API (since this will involve an application wide refactor similar to when we updated FeatureCollection).

Separately the JDBC Config module is going to implement ResourceStore backed by a database - in the fashion you describe. If the code asks for a file it will be written out to the data directory. If the code only asks for an input stream we may be able to provide that right from the database.


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

In that case I see that you already spoken and taken into account the locking mechanism.

The email discussion has a resulted in a couple additions for the FileSystemResourceStore implementation: file watcher functionality, file lock and “atomic file write”.

Please correct me if I’m wrong, as I said I did not have the chance to study the examples.

I will be looking at file lock and file watching next, so you have not missed anything yet.