Re: [Geoserver-devel] Geoserver committers to consider for nominations

2019-10-18 Thread Ian Turton 
are you suggesting I'm not a charter member? Because I am!

Ian

On Thu, 17 Oct 2019 at 22:13, Jody Garnett  wrote:

> Checking these two lists:
> - https://github.com/geoserver/geoserver/wiki/GSIP-180
> - https://www.osgeo.org/about/charter-members/
>
> We have a few gaps:
>
> - Alessandro Parma
> - Alessio Fabiani
> - Brad Hards
> - Chris Hodgson*
> - Damiano Albani
> - Daniele Romagnoli
> - Devon Tucker
> - Emanuele Tajariol
> - Fernando Mino
> - Frank Gasdorf
> - Ian Turton
> - Mauro Bartolomeoli
> - Morgan Thompson
> - Niels Charlier
> - Peter Rushforth
> - Steve Ikeoka
> - David Vick
> - Víctor González
>
> I understand that many of those names are focused on community modules.
> --
> Jody Garnett
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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

[Geoserver-devel] [JIRA] (GEOS-9371) GWC won't drop tiles for modified styles when "all styles" is used configuring the tile layer

2019-10-18 Thread Andrea Aime (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
  Andrea Aime  created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-9371  
 
 
  GWC won't drop tiles for modified styles when "all styles" is used configuring the tile layer   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 GWC  
 
 
Created: 
 18/Oct/19 12:23 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
  Andrea Aime   
 

  
 
 
 
 

 
 The tile drop integration only cares about the explicitly associated styles, but does not check the parameter filter configuration, which may allow different styles, or even "all styles". Instead of querying the GeoServer catalog the code should probably go though the tile layers instead?  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
 

[Geoserver-devel] [JIRA] (GEOS-9372) Community Keycloack plugin doc is incomplete

2019-10-18 Thread Alessio Fabiani (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
  Alessio Fabiani  created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-9372  
 
 
  Community Keycloack plugin doc is incomplete   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Community modules, OAuth2  
 
 
Created: 
 18/Oct/19 3:07 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
  Alessio Fabiani   
 

  
 
 
 
 

 
 The documentation of the plugin seems to be missing some important configuration steps as reported by a user. 

Nikola Jankovic nikola.janko...@eodc.eu tramite lists.sourceforge.net  13:40 (1 ora fa) a geoserver-us...@lists.sourceforge.net 
Hey all, 
I have discovered what is the issue. Apparently the module doesn't recognize some of the token decryption algorithms, and I solved the issue by forcing RS256 on the client and including the realm-public-key ​for RS256 in the adapter config which is located in keycloak realm settings. This isn't mentioned in the documentation though. Any way to proceed with this? 
Cheers, Nikola

Re: [Geoserver-devel] FileSystemWatcher nightmare

2019-10-18 Thread Jody Garnett 
That is ... unexpected.

So there are other solutions to notify tile cache state across the cluster
right.  Are they more appropriate then depending on file system polling
here?

On Thu, Oct 17, 2019 at 11:27 PM Gabriel Roldan 
wrote:

>
>
> On Thu, 17 Oct 2019 at 13:46, Jody Garnett  wrote:
>
>> Bad news is FileSystemWatcher is killing the machine. For each instance
>>> it gets one thread eating 100% of one CPU all the time. Reported this
>>> before, just sharing my pain.
>>>
>>> Been looking at replacing the internals of FileSystemWatcher to use
>>> java.nio.file.WatchService, and although at a first glance it looks pretty
>>> straightforward, it's not gonna be that simple.
>>>
>>
>> Darn, that was the point of making the interface (since we could not use
>> WatchService on Java 7 yet).
>>
>>
>>> There are a number of situations where it just won't work, basically
>>> when the data dir is on any sort of mapped filesystem (NFS, SAMBA, Docker
>>> bind mounts), for which the Linux implementation doesn't work as it relies
>>> on inotify.
>>>
>>> The MacOS implementation is a polling one, but it's gonna be better than
>>> the current custom one anyways. And for Windows, I don't know yet.
>>>
>>
>> Still this was only supposed to be used for a few files like the security
>> settings which require active notification? If a watcher is being setup
>> beyond that ... is it a mistake?
>>
>> In any case it's clear that anyone that has a large catalog will most
>>> probably have it on a shared filesystem to be used by several instances.
>>> So this might require a GSIP, which I'm willing to start, in order to
>>> tackle on the different scenarios, as it can get even more involved as
>>> above described.
>>>
>>
>> Before you go that far can we talk about how FileSystemWatcher is being
>> used...
>>
>
> Right. It's DefaultTileLayerCatalog listening to changes to gwc-layers/*
> in order to update tile layer configs when they're updated externally on a
> cluster (added at commit 966a8af90fc6b68725a78b09829c3cbc7360242e).
>
> For the time being, I managed to reduce the polling runtime from over 2
> minutes to ~350 milliseconds, the CPU usage from constant 100% to peaks
> bellow 25% (or so says htop). Memory usage: old gen up to 477MB from 450MB,
> eden space peaks and down quickly of 1GB instead of fixed at around 850MB.
>
> Got some clean up to do before issueing a PR, but here it is:
>
> https://github.com/groldan/geoserver/commit/0ba1614a7f9b1b2bea5647160441f3bd534c9979
>
> Gabriel
>
>>
>> --
>> Jody
>>
>
>
> --
> Gabriel Roldán
>
-- 
--
Jody Garnett
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-9373) Ducmentation Update to GetFeatureInfo Templates

2019-10-18 Thread Vera Green (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
  Vera Green  created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-9373  
 
 
  Ducmentation Update to GetFeatureInfo Templates   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Affects Versions: 
 2.15.0  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 18/Oct/19 3:51 PM  
 
 
Priority: 
  Low  
 
 
Reporter: 
  Vera Green   
 

  
 
 
 
 

 
 I am suggestion the following update to this page: https://docs.geoserver.org/stable/en/user/tutorials/GetFeatureInfo/index.html#custom-templates The Template Lookup Section: Current Documentation Says (I made green what is correct and Red what is incorrect) Look into GEOSERVER_DATA_DIR/workspacescontent.ftl to see if there is a feature type specific template Look into GEOSERVER_DATA_DIR/workspaces///content.ftl to see if there is a store specific template Look into GEOSERVER_DATA_DIR/workspaces//content.ftl to see if there is a workspace specific template Look into GEOSERVER_DATA_DIR/workspaces/content.ftl looking for a global override Look into GEOSERVER_DATA_DIR/templates/content.ftl looking for a global override Look into the GeoServer classpath and load the default template It should say: Look into GEOSERVER_DATA_DIR/templates/ for the header.ftl and footer.ftl. This directory may not exist. Create the folder and set correct folder permissions.  For a standard installation of GeoServer as a webapp in Tomcat the paths are: 
 
create a templates folder at  /opt/tomcat/webapps/geoserver/data/ 
put your header and footer in this templates folder 
put your content.ftl in /opt/tomcat/webapps/geoserver/data/workspaces to have it apply to all workspaces or as per the instructions in specific lower folders to apply at the store or layer level.

Re: [Geoserver-devel] FileSystemWatcher nightmare

2019-10-18 Thread Gabriel Roldan 
On Fri, 18 Oct 2019 at 10:17, Jody Garnett  wrote:

> That is ... unexpected.
>
> So there are other solutions to notify tile cache state across the cluster
> right.  Are they more appropriate then depending on file system polling
> here?
>

I would suspect so. The catalog does so it should be possible to do the
same with the tile layer catalog. Meanwhile I wouldn't mind this
improvement.


>
> On Thu, Oct 17, 2019 at 11:27 PM Gabriel Roldan 
> wrote:
>
>>
>>
>> On Thu, 17 Oct 2019 at 13:46, Jody Garnett 
>> wrote:
>>
>>> Bad news is FileSystemWatcher is killing the machine. For each instance
 it gets one thread eating 100% of one CPU all the time. Reported this
 before, just sharing my pain.

 Been looking at replacing the internals of FileSystemWatcher to use
 java.nio.file.WatchService, and although at a first glance it looks pretty
 straightforward, it's not gonna be that simple.

>>>
>>> Darn, that was the point of making the interface (since we could not use
>>> WatchService on Java 7 yet).
>>>
>>>
 There are a number of situations where it just won't work, basically
 when the data dir is on any sort of mapped filesystem (NFS, SAMBA, Docker
 bind mounts), for which the Linux implementation doesn't work as it relies
 on inotify.

 The MacOS implementation is a polling one, but it's gonna be better
 than the current custom one anyways. And for Windows, I don't know yet.

>>>
>>> Still this was only supposed to be used for a few files like the
>>> security settings which require active notification? If a watcher is being
>>> setup beyond that ... is it a mistake?
>>>
>>> In any case it's clear that anyone that has a large catalog will most
 probably have it on a shared filesystem to be used by several instances.
 So this might require a GSIP, which I'm willing to start, in order to
 tackle on the different scenarios, as it can get even more involved as
 above described.

>>>
>>> Before you go that far can we talk about how FileSystemWatcher is being
>>> used...
>>>
>>
>> Right. It's DefaultTileLayerCatalog listening to changes to gwc-layers/*
>> in order to update tile layer configs when they're updated externally on a
>> cluster (added at commit 966a8af90fc6b68725a78b09829c3cbc7360242e).
>>
>> For the time being, I managed to reduce the polling runtime from over 2
>> minutes to ~350 milliseconds, the CPU usage from constant 100% to peaks
>> bellow 25% (or so says htop). Memory usage: old gen up to 477MB from 450MB,
>> eden space peaks and down quickly of 1GB instead of fixed at around 850MB.
>>
>> Got some clean up to do before issueing a PR, but here it is:
>>
>> https://github.com/groldan/geoserver/commit/0ba1614a7f9b1b2bea5647160441f3bd534c9979
>>
>> Gabriel
>>
>>>
>>> --
>>> Jody
>>>
>>
>>
>> --
>> Gabriel Roldán
>>
> --
> --
> Jody Garnett
>


-- 
Gabriel Roldán
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-9374) On resource deletion data access rule get removed from UI but not from layer.properties file

2019-10-18 Thread Marco Volpini (JIRA) 
Title: Message Title


 
 
 
 

 
 
 

 
   
  Marco Volpini  created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 GeoServer /  GEOS-9374  
 
 
  On resource deletion data access rule get removed from UI but not from layer.properties file   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 18/Oct/19 4:14 PM  
 
 
Priority: 
  Medium  
 
 
Reporter: 
  Marco Volpini   
 

  
 
 
 
 

 
 When deleting layer/group/ws the associated data access rules get removed from UI but not from layer.properties file  
 

  
 
 
  
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 Get Jira notifications on your phone! Download the Jira Cloud app for Android or iOS 
  
 
 
 This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100113-

[Geoserver-devel] git config configuration

2019-10-18 Thread Jody Garnett 
I have a PR  worth some
discussion, net result of which is:

$ git config --global --get-regexp core.*

core.autocrlf input
core.safecrlf true
core.ignorecase true
core.precomposeunicode false


The "core.precomposeunicode" setting is macOS specific to prevent
committing files in a conflicting format.
The "core.ignorecse" setting is required when on a case insensitive file
system.

aside: The articles we link to no longer recommend use of core.autocrlf
input, and instead recommend taking this setting into the
repository .gitattributes file. Do we care?



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

Re: [Geoserver-devel] FileSystemWatcher nightmare

2019-10-18 Thread Jody Garnett 
Thinking further ... listening to "gwc-layers/*" is a poor idea and
unnecessary.

Since we completely know the names of these files (from their matching
layer objects). There should be no need to scan the directory for changes
... we have enough information to do this file by file which should be more
efficient when using opening system watcher.

Is it possible to detect when we are only of these mapped file systems in
order to warn the user that a different approach will be required to keep
nodes in the cluster advised of changes?
--
Jody Garnett


On Fri, 18 Oct 2019 at 07:12, Gabriel Roldan 
wrote:

>
>
> On Fri, 18 Oct 2019 at 10:17, Jody Garnett  wrote:
>
>> That is ... unexpected.
>>
>> So there are other solutions to notify tile cache state across the
>> cluster right.  Are they more appropriate then depending on file system
>> polling here?
>>
>
> I would suspect so. The catalog does so it should be possible to do the
> same with the tile layer catalog. Meanwhile I wouldn't mind this
> improvement.
>
>
>>
>> On Thu, Oct 17, 2019 at 11:27 PM Gabriel Roldan 
>> wrote:
>>
>>>
>>>
>>> On Thu, 17 Oct 2019 at 13:46, Jody Garnett 
>>> wrote:
>>>
 Bad news is FileSystemWatcher is killing the machine. For each instance
> it gets one thread eating 100% of one CPU all the time. Reported this
> before, just sharing my pain.
>
> Been looking at replacing the internals of FileSystemWatcher to use
> java.nio.file.WatchService, and although at a first glance it looks pretty
> straightforward, it's not gonna be that simple.
>

 Darn, that was the point of making the interface (since we could not
 use WatchService on Java 7 yet).


> There are a number of situations where it just won't work, basically
> when the data dir is on any sort of mapped filesystem (NFS, SAMBA, Docker
> bind mounts), for which the Linux implementation doesn't work as it relies
> on inotify.
>
> The MacOS implementation is a polling one, but it's gonna be better
> than the current custom one anyways. And for Windows, I don't know yet.
>

 Still this was only supposed to be used for a few files like the
 security settings which require active notification? If a watcher is being
 setup beyond that ... is it a mistake?

 In any case it's clear that anyone that has a large catalog will most
> probably have it on a shared filesystem to be used by several instances.
> So this might require a GSIP, which I'm willing to start, in order to
> tackle on the different scenarios, as it can get even more involved as
> above described.
>

 Before you go that far can we talk about how FileSystemWatcher is being
 used...

>>>
>>> Right. It's DefaultTileLayerCatalog listening to changes to gwc-layers/*
>>> in order to update tile layer configs when they're updated externally on a
>>> cluster (added at commit 966a8af90fc6b68725a78b09829c3cbc7360242e).
>>>
>>> For the time being, I managed to reduce the polling runtime from over 2
>>> minutes to ~350 milliseconds, the CPU usage from constant 100% to peaks
>>> bellow 25% (or so says htop). Memory usage: old gen up to 477MB from 450MB,
>>> eden space peaks and down quickly of 1GB instead of fixed at around 850MB.
>>>
>>> Got some clean up to do before issueing a PR, but here it is:
>>>
>>> https://github.com/groldan/geoserver/commit/0ba1614a7f9b1b2bea5647160441f3bd534c9979
>>>
>>> Gabriel
>>>

 --
 Jody

>>>
>>>
>>> --
>>> Gabriel Roldán
>>>
>> --
>> --
>> Jody Garnett
>>
>
>
> --
> Gabriel Roldán
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel