Re: [Geoserver-devel] (jdbc) resource store: platform additions

G'Day Niels, sorry it has taken me until the new year to return to this conversation. We discussed this pull request in the last geoserver meeting: * Andrea is creating a draft pull request review guide page to try and

Re: [Geoserver-devel] (jdbc) resource store: platform additions

On 22-12-15 23:00, Jody Garnett wrote: > > Think you are missing the idea - in most cases these resources are not > unpacked on disk and are retrieved by JDBCResourceStore. I do not know > what that will do to performance - but that is why JDBCResourceStore > is a community module. If we need

Re: [Geoserver-devel] (jdbc) resource store: platform additions

> The requirement is that if a resource listener is placed on a resource, > any change to that resource should be notified, also if that change > occurred in another instance of Geoserver in a clustered environment. Just > like the FileBasedResources notify all changes to a file. I would not >

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Hi Jody, The requirement is that if a resource listener is placed on a resource, any change to that resource should be notified, also if that change occurred in another instance of Geoserver in a clustered environment. Just like the FileBasedResources notify all changes to a file. I would not

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Thanks Neils, that approach matches my idea - I had in mind placing a listener on each style directory - and had hoped that we had relatively few other folders to track. I particular I was designing for a clustered environment and had hoped cluster workload could be sharded a bit by workspace (so

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Alright. What the clustering modules do is simply registering itself as a CatalogListener and then dispatch events to other geoserver instances. This is a fine strategy for the catalog, I don't see any reason to change it. The problem is that with resources, listeners are always placed on a

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Sounds excellent, thanks for your hard work. -- Jody Garnett On 21 December 2015 at 02:12, Niels Charlier wrote: > I'd suggest merging ResourceLoader and GeoServerDataDirectory. Both of > them provide mostly a lot of convenience methods and a little bit of extra > logic on top

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Jody, have your questions been addressed to your satisfaction? Are we ready to merge PR #1361 as it is now? https://github.com/geoserver/geoserver/pull/1361 Kind regards, Ben. On 22/12/15 15:06, Jody Garnett wrote: > Sounds excellent, thanks for your hard work. -- Ben Caradoc-Davies

Re: [Geoserver-devel] (jdbc) resource store: platform additions

I'd suggest merging ResourceLoader and GeoServerDataDirectory. Both of them provide mostly a lot of convenience methods and a little bit of extra logic on top of the ResourceStore. We can remove a lot of the depecrated stuff now. On 19-12-15 01:43, Jody Garnett wrote: And utility methods ...

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Looks like the methods have been addressed, still circling a bit on the event notification. What is your impression Niels? -- Jody Garnett On 21 December 2015 at 18:26, Ben Caradoc-Davies wrote: > Jody, > > have your questions been addressed to your satisfaction? Are we

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Hi Jody, Thanks for your review. On 17-12-15 00:36, Jody Garnett wrote: > - architecture reason: I was trying to have ResourceStore be the > single source of truth for resources (including change notification). > Is there a reason why this should change? Yes and no. There is a very clear

Re: [Geoserver-devel] (jdbc) resource store: platform additions

On 18-12-15 16:04, Niels Charlier wrote: > >> - yeah I know you did not write this - just added one that takes a >> URL (do you really need both?) > > Yes, you do. The fromURL(String) method accepts things that would be > rejected by a normal URL parser, abolishing it would be a serious >

Re: [Geoserver-devel] (jdbc) resource store: platform additions

And utility methods ... 2) New utility methods >> >> Resources.toURL( resource ) >> - makes a lot of sense and reads better in the code >> >> I am not too worried about additional utility methods, instead I am >> concerned about changes to objects we may have to implement (such as >>

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Comments inline on event distribution ... and then we should be good to go. If it helps I think we can seperate event notification (generating events/listening for events) from event distribution (in a cluster, recorded in an audit log). On 18 December 2015 at 07:04, Niels Charlier

Re: [Geoserver-devel] (jdbc) resource store: platform additions

Thanks Niels for taking this to the development list, I would like to ask you to bring these things up as they occur to you (rather than wait for the pull request review ) this will make your pull requests easier to review and more efficient for everyone here. Or you can work like Justin and

Re: [Geoserver-devel] Jdbc resource store

Jody, On 07/24/2015 10:28 PM, Jody Garnett wrote: Still we may be thinking in a different direction. The initial import from data directory to JDBCConfig is a one time journey. After that the idea is to manage via REST API (yes ResourceStore still needs a REST API). It sounds like you are

Re: [Geoserver-devel] Jdbc resource store

On 23-07-15 18:45, Jody Garnett wrote: I implemented replacement watchers as part of the migration? Are they not working for you ... And that code should still work, the directory will get unpacked - but it is not any kind of fun. If the changes are picked up and written to the db

Re: [Geoserver-devel] Jdbc resource store

Have a look at the examples I linked to. We need a second QA pass through the codebase to remove references to files (and deprecate methods like getOrCreateDirectory). For the first pass I just implemented them all in terms of Resource - but any code that asks for a file will get one (unpacking

Re: [Geoserver-devel] Jdbc resource store

On 23-07-15 17:53, Jody Garnett wrote: Have a look at the examples I linked to. We need a second QA pass through the codebase to remove references to files (and deprecate methods like getOrCreateDirectory). For the first pass I just implemented them all in terms of Resource - but any code

Re: [Geoserver-devel] Jdbc resource store

Hi Jody, On 23-07-15 17:53, Jody Garnett wrote: Have a look at the examples I linked to. We need a second QA pass through the codebase to remove references to files (and deprecate methods like getOrCreateDirectory). For the first pass I just implemented them all in terms of Resource - but

Re: [Geoserver-devel] Jdbc resource store

On 23-07-15 07:05, Jody Garnett wrote: Directories do not exist until needed, just like resources are not created until needed. We worked hard to simplify all the common checks including that one :) So for a file system resource store if you create a resource using resource.out() the file (and

Re: [Geoserver-devel] Jdbc resource store

On 23-07-15 10:16, Niels Charlier wrote: On 23-07-15 07:05, Jody Garnett wrote: Directories do not exist until needed, just like resources are not created until needed. We worked hard to simplify all the common checks including that one :) So for a file system resource store if you create a

Re: [Geoserver-devel] Jdbc resource store

On Tue, Jul 21, 2015 at 6:18 PM Niels Charlier ni...@scitus.be wrote: Hi Kevin and Gabriel, I have a few questions regarding the jdbc resource store and the resource store API in general that I'd like to hear your opinion on. Including the mailing list because others might have thoughts on