Re: [Geoserver-devel] OGC Features to supported status

[Gabriel Roldan]

Hi All,

I apologize for the slow response and thank you all for your detailed and
valuable contributions to this thread.

I am still waiting for funding confirmation, but I want to emphasize the
importance of approaching this as a community-driven, collaborative effort.

Once funding is secured, our focus will be on ensuring that the OGC
Features API meets production readiness as per customer requirements.
Consequently, any refactoring, design, or architectural decisions must be
made collaboratively to ensure that other API implementations can
seamlessly follow suit where applicable.

To this end, I propose we develop a plan to initially refactor the
gs-ogcapi-core and gs-ogcapi-features modules as extensions. Based on the
concerns and ideas discussed in this thread, we should work towards the
following objectives:

* Defining and Implementing Service Metadata Independent of WFS
Configuration:

Currently, the service metadata and configuration for the OGC Features
module use the WFS service configuration. We need to decouple it from the
WFS configuration, and the exact approach is open for discussion.

* Designing and Implementing a Mechanism to Enable/Disable Non-Finalized
Parts of the Specification:

The OGC Features API is divided into separate specifications, some of which
are not finalized. It is crucial that these unfinished aspects of the API
can be enabled or disabled via configuration. This configuration will
likely be part of the ogcapi-specific service configuration mentioned above.

* Setting Up CI/CD Pipelines:

We need to establish and integrate continuous integration and deployment
pipelines for automated testing. These pipelines should run CITE
conformance tests and additional integration tests (e.g., against PostGIS).

* Providing a Technical Preview Distribution of GeoServer:

A technical preview distribution of GeoServer with the OGC APIs enabled
will allow us to reach a wider audience for testing and early feedback.

* Organizing a Code Sprint:

To complement community discussions on design and implementation, it would
be ideal to organize an online code sprint. Although we may not have
sufficient funding for an on-site event, an online code sprint would still
enable all interested parties to contribute focused time and effort.
Thank you again for your initial thoughts. I look forward to getting
started and hearing from all of you.

Best regards,
Gabe
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Sat, Jul 6, 2024 at 8:07 AM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Alexandre,
> indeed they did. At the same time, the existing OWS APIs have been around
> for such a long time,
> what is the meaning of "deprecating", besides a formal statement? That
> will have some effect on
> large, formal organisations, but the rest of the world will carry on
> unscathed.
>
> The worst they can do is to remove the schemas from
> https://schemas.opengis.net/... that may
> have some effect, but the net result will be to mostly piss off people and
> give them a reason
> to choose an "open specification" rather than an official standard, and
> just prompt developers
> to make sure their software is working offline (AFAIk Geoserver does not
> need the schemas
> over there, effort was put in to work mostly offline, but I may be wrong
> and/or some
> cases might not actually work).
>
> Regards,
>
> Andrea Aime
>
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
>
> On Sat, Jul 6, 2024 at 1:55 PM Alexandre Gacon 
> wrote:
>
>> Regarding OGC web services vs OGC API, during the OGC 

Re: [Geoserver-devel] Attempting to upgrade Marlin, WIP and request for assistance

[Gabriel Roldan]

On Sun, Jul 7, 2024 at 11:51 AM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi all,
> during the GeoServer workshops at FOSS4G EU people showed up
> with Java 17 or 21 by default, and we know the bin package does not work
> in that context.
> I have made a quick attempt at updating to the latest, and using the
> system module (Java 11+) to integrate it, here:
>
> I've made some tests with the JVM's I've installed and commented on the
pr.

> https://github.com/geoserver/geoserver/pull/7760
>
> It's a draft pull request from a shared branch, help welcomed.
> I've also created a ready to test bin package for those that want to try
> it out:
>
> Let me know if it works for you, on which OS and Java, and if not, let me
> know anyways, extra points for those that can also provide a suggestion on
> how to fix the startup.sh/startup.bat to make it work:
>
> https://www.dropbox.com/scl/fi/yw8rsp1n3hx4vszyxmne7/geoserver-2.26-SNAPSHOT-bin-marlin-latest.zip?rlkey=852pcth2wvhpesp04f1yrixft=vn0tv0ne=1
>
>
> The objective is really simple: get GeoServer running in all LTS Java
> versions supported, across various OSs.
>
> Regards,
>
> Andrea Aime
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Motion to Promote Camptocamp to Experienced Provider

[Gabriel Roldan]

Hello,

I've created a pull request to move camptocamp from additional
to experienced provider here:
https://github.com/geoserver/geoserver.github.io/pull/202

Looking forward to your feedback.

Cheers,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Mon, Jun 24, 2024 at 6:55 PM Gabriel Roldan <
gabriel.rol...@camptocamp.com> wrote:

>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Developer
>
>
>
> On Mon, Jun 24, 2024 at 4:09 PM Jody Garnett 
> wrote:
>
>> A little more work is needed for your application (see the instructions
>> you linked to
>> https://docs.geoserver.org/latest/en/developer/policies/service_providers.html
>> ).
>>
>
> Yes, it wasn't clear whether I should include the links in the email. It
> was more to gather PSC sentiment and eventually provide the links in the
> pull request.
>
> Question on editing the page:
>
>
>>
>>- Development: easy https://github.com/geoserver/geoserver-cloud
>>
>>  https://github.com/geoserver/geoserver-cloud
>
>
>
>>- Coding: easy https://github.com/geotools/geotools/pulls/groldan
>>
>>
> https://github.com/geoserver/geoserver/pulls/groldan?q=is%3Aclosed
> https://github.com/geotools/geotools/pulls/groldan?q=is%3Aclosed
> https://github.com/geotools/geotools/pulls/vuilleumierc?q=is%3Aclosed
> https://github.com/geotools/geotools/pulls/pmauduit?q=is%3Aclosed
> https://github.com/geoserver/geoserver/pulls/pmauduit?q=is%3Aclosed
>
>
>>
>>- Translation: I am not sure how to check this?!
>>
>> I'm under the impression Alex Gacon worked on translation. Gotta confirm
>
>
>>
>>- Outreach: I have done some presentations with you previously?
>>Looking for a link https://2024.europe.foss4g.org/schedule/talks/ but
>>did not see one ...
>>
>> https://talks.osgeo.org/foss4g-europe-2024/talk/3NXTEG/
> https://talks.osgeo.org/foss4g-europe-2024/talk/GHRLE3/
> https://talks.osgeo.org/foss4g-2023/talk/GK3YMN/
> https://talks.osgeo.org/foss4g-2023/talk/9R3QTM/
>
>
>>
>>- Training: link? Do you have a geoserver training page? I am not
>>familiar with camptocamp offerings...
>>
>>
>
> https://camptocamp.com/en/trainings/manage-and-administer-a-georchestra-platform
> https://github.com/camptocamp/courseware-geoserver
> I'm sure there's more but it's too late for may european colleages to
> answer right now
>
>
>>- Services: link? Do you have a specific geoserver support page?
>>
>> https://camptocamp.com/geoserver
>
>
>>
>>- Product: link? Do you have a specific geoserver product? Or product
>>that contains geoserver?
>>
>> https://www.georchestra.org/
>
>
>>
>> I am comfortable with camptocamp as an experienced provider; I would also
>> consider the "cloud native geoserver" to be close to an extension (someone
>> more than a community module?)
>>
>
> I'd say it's closer to product in the same way geoserver is advertised as
> product in other providers' pages, but I wouldn't date that much without
> the packaging and the bow
>
>
>>
>> Do you want to start making a pull request?
>>
>
> yes, thanks, I'll prepare a pr as soon as possible.
>
> Cheers,
>
>
>> --
>> Jody Garnett
>>
>>
>> On Jun 24, 2024 at 7:40:59 AM, Gabriel Roldan <
>> gabriel.rol...@camptocamp.com> wrote:
>>
>>> Hi PSC,
>>>
>>> I am writing to nominate Camptocamp for promotion to an Experienced
>>> Provider and to have them listed as such on the GeoServer Commercial
>>> Support page [1].
>>>
>>> Based on the requirements outlined in the developer documentation[2],
>>> Camptocamp appears to meet 8 out of the 9 criteria:
>>>
>>> ✓ Development
>>> ✓ Coding
>>> x Documentation contributions to the user guide or similar
>>> ✓ Translation
>>> ✓ Outreach
>>> ✓ Training
>>> ✓ Services
>>> ✓ Product
>>>
>>> I look forward to your feedback on this nomination.
>>>
>>> Thank you in advance for your consideration.
>>>
>>> Best regards,
>>> Gabe
>>>
>>> [1] https://geoserver.org/support/
>>> [2]
>>> https://docs.geoserver.org/latest/en/developer/policies/service_providers.html
>>>
>> *camptocamp*
>>> INNOVATIVE SOLUTIONS
>>> BY OPEN SOURCE EXPERTS
>>>
>>> *Gabriel Roldán*
>>> Geospatial Developer
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Motion to Promote Camptocamp to Experienced Provider

[Gabriel Roldan]

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Mon, Jun 24, 2024 at 4:09 PM Jody Garnett  wrote:

> A little more work is needed for your application (see the instructions
> you linked to
> https://docs.geoserver.org/latest/en/developer/policies/service_providers.html
> ).
>

Yes, it wasn't clear whether I should include the links in the email. It
was more to gather PSC sentiment and eventually provide the links in the
pull request.

Question on editing the page:


>
>- Development: easy https://github.com/geoserver/geoserver-cloud
>
>  https://github.com/geoserver/geoserver-cloud



>- Coding: easy https://github.com/geotools/geotools/pulls/groldan
>
>
https://github.com/geoserver/geoserver/pulls/groldan?q=is%3Aclosed
https://github.com/geotools/geotools/pulls/groldan?q=is%3Aclosed
https://github.com/geotools/geotools/pulls/vuilleumierc?q=is%3Aclosed
https://github.com/geotools/geotools/pulls/pmauduit?q=is%3Aclosed
https://github.com/geoserver/geoserver/pulls/pmauduit?q=is%3Aclosed


>
>- Translation: I am not sure how to check this?!
>
> I'm under the impression Alex Gacon worked on translation. Gotta confirm


>
>- Outreach: I have done some presentations with you previously?
>Looking for a link https://2024.europe.foss4g.org/schedule/talks/ but
>did not see one ...
>
> https://talks.osgeo.org/foss4g-europe-2024/talk/3NXTEG/
https://talks.osgeo.org/foss4g-europe-2024/talk/GHRLE3/
https://talks.osgeo.org/foss4g-2023/talk/GK3YMN/
https://talks.osgeo.org/foss4g-2023/talk/9R3QTM/


>
>- Training: link? Do you have a geoserver training page? I am not
>familiar with camptocamp offerings...
>
>
https://camptocamp.com/en/trainings/manage-and-administer-a-georchestra-platform
https://github.com/camptocamp/courseware-geoserver
I'm sure there's more but it's too late for may european colleages to
answer right now


>- Services: link? Do you have a specific geoserver support page?
>
> https://camptocamp.com/geoserver


>
>- Product: link? Do you have a specific geoserver product? Or product
>that contains geoserver?
>
> https://www.georchestra.org/


>
> I am comfortable with camptocamp as an experienced provider; I would also
> consider the "cloud native geoserver" to be close to an extension (someone
> more than a community module?)
>

I'd say it's closer to product in the same way geoserver is advertised as
product in other providers' pages, but I wouldn't date that much without
the packaging and the bow


>
> Do you want to start making a pull request?
>

yes, thanks, I'll prepare a pr as soon as possible.

Cheers,


> --
> Jody Garnett
>
>
> On Jun 24, 2024 at 7:40:59 AM, Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi PSC,
>>
>> I am writing to nominate Camptocamp for promotion to an Experienced
>> Provider and to have them listed as such on the GeoServer Commercial
>> Support page [1].
>>
>> Based on the requirements outlined in the developer documentation[2],
>> Camptocamp appears to meet 8 out of the 9 criteria:
>>
>> ✓ Development
>> ✓ Coding
>> x Documentation contributions to the user guide or similar
>> ✓ Translation
>> ✓ Outreach
>> ✓ Training
>> ✓ Services
>> ✓ Product
>>
>> I look forward to your feedback on this nomination.
>>
>> Thank you in advance for your consideration.
>>
>> Best regards,
>> Gabe
>>
>> [1] https://geoserver.org/support/
>> [2]
>> https://docs.geoserver.org/latest/en/developer/policies/service_providers.html
>>
> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Motion to Promote Camptocamp to Experienced Provider

[Gabriel Roldan]

Hi PSC,

I am writing to nominate Camptocamp for promotion to an Experienced
Provider and to have them listed as such on the GeoServer Commercial
Support page [1].

Based on the requirements outlined in the developer documentation[2],
Camptocamp appears to meet 8 out of the 9 criteria:

✓ Development
✓ Coding
x Documentation contributions to the user guide or similar
✓ Translation
✓ Outreach
✓ Training
✓ Services
✓ Product

I look forward to your feedback on this nomination.

Thank you in advance for your consideration.

Best regards,
Gabe

[1] https://geoserver.org/support/
[2]
https://docs.geoserver.org/latest/en/developer/policies/service_providers.html
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

[Geoserver-devel] OGC Features to supported status

[Gabriel Roldan]

Hi all,

Camptocamp is interested in contributing to graduate the gs-ogcapi-features
module (and by extension gs-ogcapi-core) to supported status.

I'll be getting used to it, but wonder if that's an achievable goal and if
you have any clue of what it would entail.

Cheers,
Gabe
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] [Geoserver-users] Error using function Interpolate in COLOR mode from SLD

[Gabriel Roldan]

Moving the discussion to the devel list.

Please check the following pull request:
https://github.com/geotools/geotools/pull/4819

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Fri, Jun 21, 2024 at 10:50 AM Alexandre Gacon 
wrote:

> Gabriel Roldan is taking care of it.
>
> Alexandre
>
> Le ven. 21 juin 2024 à 15:45, Alexandre Gacon 
> a écrit :
>
>> I initiated the ticket https://osgeo-org.atlassian.net/browse/GEOT-7607.
>>
>> Regards
>> Alexandre
>>
>> Le ven. 21 juin 2024 à 14:58, Andrea Aime <
>> andrea.a...@geosolutionsgroup.com> a écrit :
>>
>>> Hi Steve,
>>> yes, that commit is involved, as it triggers a bug in the function
>>> implementation.
>>> A function must not rely on the context object being set, the context is
>>> provided only so that the function can try to covert
>>> its result towards it. Passing in "null" or "object" means "do what you
>>> want, we're not asking for a particular type of output",
>>> but the current implementation throws an exception instead. Looks like
>>> the error predates the git history (14+ years)
>>> In any case, that needs to be fixed.
>>>
>>> Regards,
>>>
>>> Andrea Aime
>>>
>>>
>>> ==
>>> GeoServer Professional Services from the experts!
>>>
>>> Visit http://bit.ly/gs-services-us for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions Group
>>> phone: +39 0584 962313
>>>
>>> fax: +39 0584 1660272
>>>
>>> mob:   +39  339 8844549
>>>
>>> https://www.geosolutionsgroup.com/
>>>
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>>
>>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>> precisa che ogni circostanza inerente alla presente email (il suo
>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail
>>>
>>>
>>> On Mon, Jun 17, 2024 at 11:16 PM Ikeoka, Steve via Geoserver-users <
>>> geoserver-us...@lists.sourceforge.net> wrote:
>>>
>>>> There isn't enough of the stack trace provided but this commit is a
>>>> possible source of the regression (GeoServer 2.23.3+):
>>>> https://github.com/geotools/geotools/commit/d7991fdcd1630ea1c18b5dfad91d4e291b8bb95b
>>>>
>>>> Steve Ikeoka
>>>> --
>>>> *From:* Jody Garnett 
>>>> *Sent:* Monday, June 17, 2024 10:17 AM
>>>> *To:* Carsten Klein 
>>>> *Cc:* GeoServer Mailing List List <
>>>> geoserver-us...@lists.sourceforge.net>
>>>> *Subject:* Re: [Geoserver-users] Error using function Interpolate in
>>>> COLOR mode from SLD
>>>>
>>>> It is more that I am not aware of any change that could cause this
>>>> regression. Were you able to determine when the problem was introduced and
>>>> report the issue to the issue tracker? I am curious to what you will find.
>>>> Determing which release
>>>> ZjQcmQRYFpfptBannerStart
>>>> This Message Is From an External Sender
>>>> Please use caution with links, attachments, and any requests for
>>>> credentials.
>>>>
>>>> ZjQcmQRYFpfptBannerEnd
>>>> It is more that I am not aware of any change that could cause this
>>>> regression.
>>>>
>>>> Were you able to determine when the problem was introd

Re: [Geoserver-devel] Use securityFilter in SecureCatalogImpl bulk get methods

[Gabriel Roldan]

oops, forgot to add link https://osgeo-org.atlassian.net/browse/GEOS-11423
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Thu, May 30, 2024 at 3:27 PM Gabriel Roldan <
gabriel.rol...@camptocamp.com> wrote:

> I went ahead and created a jira ticket, mostly for internal tracking
> purposes.
> If there's anything to discuss please follow up in there?
>
> cheers,
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Developer
>
>
>
> On Thu, May 30, 2024 at 12:16 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> I've noticed quite an overhead in dealing with large catalogs coming from
>> SecureCatalogImpl.getXXX():List<> methods
>>
>> Reason being it does a "full table scan" and filters in-process, while
>> the list(Class, Filter,...):Iterator method relies on the
>> ResourceAccessManager build of a security filter.
>>
>> I've created a draft pull request here:
>> https://github.com/geoserver/geoserver/pull/7698
>>
>> So far everything seems to be working, but I'm not sure if I may be
>> missing something.
>>
>> If this seems like something we can accept I'll create a jira ticket and
>> follow procedure.
>>
>> Cheers,
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Use securityFilter in SecureCatalogImpl bulk get methods

[Gabriel Roldan]

I went ahead and created a jira ticket, mostly for internal tracking
purposes.
If there's anything to discuss please follow up in there?

cheers,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Thu, May 30, 2024 at 12:16 PM Gabriel Roldan <
gabriel.rol...@camptocamp.com> wrote:

> I've noticed quite an overhead in dealing with large catalogs coming from
> SecureCatalogImpl.getXXX():List<> methods
>
> Reason being it does a "full table scan" and filters in-process, while the
> list(Class, Filter,...):Iterator method relies on the ResourceAccessManager
> build of a security filter.
>
> I've created a draft pull request here:
> https://github.com/geoserver/geoserver/pull/7698
>
> So far everything seems to be working, but I'm not sure if I may be
> missing something.
>
> If this seems like something we can accept I'll create a jira ticket and
> follow procedure.
>
> Cheers,
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Developer
>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Match webui workspace admin functionality in the REST API

[Gabriel Roldan]

https://osgeo-org.atlassian.net/browse/GEOS-11421
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Thu, May 30, 2024 at 12:32 PM Gabriel Roldan <
gabriel.rol...@camptocamp.com> wrote:

> Okay, I'll create a ticket then.
>
> Given we can implement without breaking API I guess a GSIP wouldn't be
> necessary?
>
> Questions to Geofence experts:
>
> An AdminRule's grant type can be ADMIN or USER.
> The semantics for ADMIN are pretty clear, but I'm having trouble
> determining if USER has any practical implications.
> May it be that an AdminRule with USER grant should give read-only access
> to the workspace and its nested objects?
>
> Also, thinking forward about this proposal, I'm wondering what'd be the
> right way to handle AdminRule and Rule collisions in terms of data access.
> Let's say a user has ADMIN rights to a workspace, but the data-access
> Rules don't let him see that workspace.
> * Does it mean the user can admin (and hence see) the workspace and its
> nested objects for admin purposes, but can't do any service requests?
> (GetMap, etc)
> * Should the workspace ADMIN rule override the data access rules and let
> him also access the workspace/layers?
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Developer
>
>
>
> On Thu, May 30, 2024 at 12:13 PM Jody Garnett 
> wrote:
>
>> Nice timing Gabe,
>>
>> I actually ran into this disconnect last week also (testing the geocat
>> bridge plugin which uses the REST API). It would be nice to provide access
>> for automation limited to specific workspaces.
>> --
>> Jody Garnett
>>
>>
>> On May 30, 2024 at 8:08:51 AM, Gabriel Roldan <
>> gabriel.rol...@camptocamp.com> wrote:
>>
>>> Hey all,
>>>
>>> The mentioning of unmatched webui/rest functionality for URL checks in
>>> the other thread reminded me I wanted to bring up this topic too.
>>>
>>> Thing is, ResourceAccessManager (default, geofence, geoserver-acl)
>>> allows defining if a user is a workspace administrator. If so, the webui
>>> will allow him to administer them, limiting the listed catalog objects
>>> accordingly.
>>>
>>> But the matching functionality is not available through the REST API. It
>>> would make sense, IMHO, that if a user has admin rights to a workspace, it
>>> can administer it both through the webui and the rest api, allowing access
>>> to the following paths:
>>>
>>> /rest/workspaces/ (limiting the visibility to the adminable workspaces)
>>> /rest/workspaces/
>>> /rest/workspaces//**
>>> /rest/resource/workspaces/ (limiting the visibility to the adminable
>>> workspaces)
>>> /rest/resource/workspaces//**
>>>
>>> This can be implemented with an additional, ResourceAcessManager-backed
>>> AccessDecisionVoter in GeoServerSecurityInterceptorFilter, so that instead
>>> of fully overriding the security/rest.properties config file, it'd
>>> complement it.
>>>
>>> Does this make sense?
>>>
>>> *camptocamp*
>>> INNOVATIVE SOLUTIONS
>>> BY OPEN SOURCE EXPERTS
>>>
>>> *Gabriel Roldán*
>>> Geospatial Developer
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] is CatalogListener.reloaded() dead code?

[Gabriel Roldan]

Cool,
created https://osgeo-org.atlassian.net/browse/GEOS-11420
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Mon, May 27, 2024 at 7:48 AM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
> yes that seems a good idea!
>
> Regards,
>
> Andrea Aime
>
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
>
> On Tue, May 21, 2024 at 3:40 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi Andrea,
>> yes I remember you had to deal with the reckless deprecation trend, all
>> good. I didn't check exactly when CatalogListener.reloaded() stopped
>> being called though.
>> In any case, the ones I've in the classpath look pretty important (see
>> below).
>> About migrating the current CatalogListeners to
>> GeoServerLifecycleHandlers, I think that'd be rather complicated.
>> What if instead we had a GeoServerLifecycleHandler that on its onReload()
>> method calls reloaded() on all the catalog listeners?
>> GeoServerImpl.reload(Catalog newCatalog) seems to be the only entry
>> point to trigger the config and catalog reload, and it end up by doing
>> callLifecycleHandlers(GeoServerLifecycleHandler::onReload, "onReload");
>> so it seems like it could work out of the box?
>>
>> - *LayerGroupContainmentCache$CatalogChangeListener*:
>> @Override
>> public void reloaded() {
>> // rebuild the containment cache
>> buildLayerGroupCaches();
>> }
>> - *LegendSampleImpl*:
>> @Override
>> public void reloaded() {
>> clean();
>> }
>> - *MimeTypeCacheClearingListener:*
>> @Override
>> public void reloaded() {
>> outputMimeTypes.clear();
>> }
>> - *WFSConfiguration*'\s anonymous inner class:
>> @Override
>> public void reloaded() {
>> wfs.dispose();
>> }
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>>
>>
>> On Mon, May 20, 2024 at 11:41 AM Andrea Aime <
>> andrea.a...@geosolutionsgroup.com> wrote:
>>
>>> Hi Gabriel,
>>> I don't remember why it was un-deprecated, I guess the activity was
>>> related to removing all
>>> deprecated API and its usage points, and this one seemed to be used.
>>> The was an unfortunate trend back then to deprecate carelessly APIs here
>>> and there, without checking usage points and
>>> checking consequences, something that the new QA build luckily forbids
>>> (deprecation is possible, but one has to go and
>>> clean up usage points, learn what migration paths are needed and provide
>>> them in the PR as well).
>>>
>>> I'm only guessing that I saw usage points and un-deprecated, without
>>> noticing that there were only
>>> listener implementations, but not callers.
>>>
>>> We can remove it, the current listeners using it should be verified...
>>> do they need to migrate
>>> on the lifecycle lis

Re: [Geoserver-devel] Match webui workspace admin functionality in the REST API

[Gabriel Roldan]

Okay, I'll create a ticket then.

Given we can implement without breaking API I guess a GSIP wouldn't be
necessary?

Questions to Geofence experts:

An AdminRule's grant type can be ADMIN or USER.
The semantics for ADMIN are pretty clear, but I'm having trouble
determining if USER has any practical implications.
May it be that an AdminRule with USER grant should give read-only access to
the workspace and its nested objects?

Also, thinking forward about this proposal, I'm wondering what'd be the
right way to handle AdminRule and Rule collisions in terms of data access.
Let's say a user has ADMIN rights to a workspace, but the data-access Rules
don't let him see that workspace.
* Does it mean the user can admin (and hence see) the workspace and its
nested objects for admin purposes, but can't do any service requests?
(GetMap, etc)
* Should the workspace ADMIN rule override the data access rules and let
him also access the workspace/layers?

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Thu, May 30, 2024 at 12:13 PM Jody Garnett 
wrote:

> Nice timing Gabe,
>
> I actually ran into this disconnect last week also (testing the geocat
> bridge plugin which uses the REST API). It would be nice to provide access
> for automation limited to specific workspaces.
> --
> Jody Garnett
>
>
> On May 30, 2024 at 8:08:51 AM, Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hey all,
>>
>> The mentioning of unmatched webui/rest functionality for URL checks in
>> the other thread reminded me I wanted to bring up this topic too.
>>
>> Thing is, ResourceAccessManager (default, geofence, geoserver-acl) allows
>> defining if a user is a workspace administrator. If so, the webui will
>> allow him to administer them, limiting the listed catalog objects
>> accordingly.
>>
>> But the matching functionality is not available through the REST API. It
>> would make sense, IMHO, that if a user has admin rights to a workspace, it
>> can administer it both through the webui and the rest api, allowing access
>> to the following paths:
>>
>> /rest/workspaces/ (limiting the visibility to the adminable workspaces)
>> /rest/workspaces/
>> /rest/workspaces//**
>> /rest/resource/workspaces/ (limiting the visibility to the adminable
>> workspaces)
>> /rest/resource/workspaces//**
>>
>> This can be implemented with an additional, ResourceAcessManager-backed
>> AccessDecisionVoter in GeoServerSecurityInterceptorFilter, so that instead
>> of fully overriding the security/rest.properties config file, it'd
>> complement it.
>>
>> Does this make sense?
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Use securityFilter in SecureCatalogImpl bulk get methods

[Gabriel Roldan]

I've noticed quite an overhead in dealing with large catalogs coming from
SecureCatalogImpl.getXXX():List<> methods

Reason being it does a "full table scan" and filters in-process, while the
list(Class, Filter,...):Iterator method relies on the ResourceAccessManager
build of a security filter.

I've created a draft pull request here:
https://github.com/geoserver/geoserver/pull/7698

So far everything seems to be working, but I'm not sure if I may be missing
something.

If this seems like something we can accept I'll create a jira ticket and
follow procedure.

Cheers,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

[Geoserver-devel] Match webui workspace admin functionality in the REST API

[Gabriel Roldan]

Hey all,

The mentioning of unmatched webui/rest functionality for URL checks in the
other thread reminded me I wanted to bring up this topic too.

Thing is, ResourceAccessManager (default, geofence, geoserver-acl) allows
defining if a user is a workspace administrator. If so, the webui will
allow him to administer them, limiting the listed catalog objects
accordingly.

But the matching functionality is not available through the REST API. It
would make sense, IMHO, that if a user has admin rights to a workspace, it
can administer it both through the webui and the rest api, allowing access
to the following paths:

/rest/workspaces/ (limiting the visibility to the adminable workspaces)
/rest/workspaces/
/rest/workspaces//**
/rest/resource/workspaces/ (limiting the visibility to the adminable
workspaces)
/rest/resource/workspaces//**

This can be implemented with an additional, ResourceAcessManager-backed
AccessDecisionVoter in GeoServerSecurityInterceptorFilter, so that instead
of fully overriding the security/rest.properties config file, it'd
complement it.

Does this make sense?

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] Thinking about community modules packaging

[Gabriel Roldan]

I'm afraid this would solve the packaging issue but not the problem of
deploying both the COG and the Azure blobstore extensions, as you'd end up
with duplicate netty dependencies with incompatible versions.

In GeoServer Cloud I had to deal with this specific issue, using the
"dependencyConvergence" maven enforcer plugin rule [1], and ensuring a
single version of each duplicate dependency is in place. With the
additional overhead of ensuring the plugins whose dependencies are
overridden still work.

For the specific case of the netty version, I'm pegging it to 4.1.41.Final.
Both COG and Azure blobstore work with that one.
The libs are in the pom's "dependencyConvergence" maven profile [3].

So probably we could do something similar in geoserver to ensure a single
version of each dependency is ever present.
Though that'd probably open its own can of worms. Perhaps just making sure
both COG and Azure blobstore carry over netty 4.1.41.Final would suffice
for the time being, without a rewrite of the Azure blobstore?

[1] https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L904
[2]
https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L30-L32
[3]
https://github.com/geoserver/geoserver-cloud/blob/main/src/pom.xml#L1070-L1124
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Wed, May 29, 2024 at 12:35 PM Lahr-Vivaz, Emilio <
emilio.lahr-vi...@ga-ccri.com> wrote:

> Sounds good, dependency sets do provide include/exclude filtering[1] (or
> if the pom already has things correctly scoped as provided vs compile then
> you can easily filter out provided), but I'm all for easy wins!
>
> Thanks,
>
> Emilio
>
> [1]:
> https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
>
> *Emilio Lahr-Vivaz*
> General Atomics, CCRi
> --
> *From:* Andrea Aime 
> *Sent:* Wednesday, May 29, 2024 11:15 AM
> *To:* Lahr-Vivaz, Emilio 
> *Cc:* Jody Garnett ; GeoServer <
> geoserver-devel@lists.sourceforge.net>
> *Subject:* Re: [Geoserver-devel] Thinking about community modules
> packaging
>
> Hi Emilio,
> I'm aware of it, but there are issues... one one side, we want to package
> in the zip file only the jars that are not already covered by core.
> The other bit is, even if there was a way to achieve the above, all 74
> community module packaging files would have to be individually rewritten.
>
> What I'm proposing is simple, mechanical, and can be at least partially
> automated, which means, it fits a small budget.
> If we can party up with several people and attempt a technically better
> approach, so that my isolated effort is more or less the same,
> I'm all for it!
>
> Regards,
>
> Andrea Aime
>
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
>
> On Wed, May 29, 2024 at 5:06 PM Lahr-Vivaz, Emilio <
> emilio.lahr-vi...@ga-ccri.com> wrote:
>
> If it's helpful, the maven assembly plugin has a concept of
> 'dependencySets', which could replace some of the fileSets and allow you to
> avoid running dependencies:dependency-copy.
>
> Thanks,
>
> Emilio
>
> --
> *From:* Andrea Aime 
> *Sent:* Wednesday, May 29, 2024 10:40 AM
> *To:* Jody Garnett 
> *Cc:* GeoServer 
> *Subject:* Re: [Geoserver-devel] Thinking about community modules
> packaging
>
> Hi Jody.
> yes each module would have the assembly configuration local, besides its
> pom.xml.
> I've made a small experiment, on the COG module alone, this should work:
>
> 
>   cog-plugin
>   
> zip
>   
>   false
>   
> 
>   target/dependency
> 

Re: [Geoserver-devel] is CatalogListener.reloaded() dead code?

[Gabriel Roldan]

Hi Andrea,
yes I remember you had to deal with the reckless deprecation trend, all
good. I didn't check exactly when CatalogListener.reloaded() stopped being
called though.
In any case, the ones I've in the classpath look pretty important (see
below).
About migrating the current CatalogListeners to GeoServerLifecycleHandlers,
I think that'd be rather complicated.
What if instead we had a GeoServerLifecycleHandler that on its onReload()
method calls reloaded() on all the catalog listeners?
GeoServerImpl.reload(Catalog newCatalog) seems to be the only entry point
to trigger the config and catalog reload, and it end up by doing
callLifecycleHandlers(GeoServerLifecycleHandler::onReload, "onReload");
so it seems like it could work out of the box?

- *LayerGroupContainmentCache$CatalogChangeListener*:
@Override
public void reloaded() {
// rebuild the containment cache
buildLayerGroupCaches();
}
- *LegendSampleImpl*:
@Override
public void reloaded() {
clean();
}
- *MimeTypeCacheClearingListener:*
@Override
public void reloaded() {
outputMimeTypes.clear();
}
- *WFSConfiguration*'\s anonymous inner class:
@Override
public void reloaded() {
wfs.dispose();
}
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Mon, May 20, 2024 at 11:41 AM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
> I don't remember why it was un-deprecated, I guess the activity was
> related to removing all
> deprecated API and its usage points, and this one seemed to be used.
> The was an unfortunate trend back then to deprecate carelessly APIs here
> and there, without checking usage points and
> checking consequences, something that the new QA build luckily forbids
> (deprecation is possible, but one has to go and
> clean up usage points, learn what migration paths are needed and provide
> them in the PR as well).
>
> I'm only guessing that I saw usage points and un-deprecated, without
> noticing that there were only
> listener implementations, but not callers.
>
> We can remove it, the current listeners using it should be verified... do
> they need to migrate
> on the lifecycle listeners, or are they redundant and simply be removed?
>
> Regards,
>
> Andrea Aime
>
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>
>
> On Mon, May 20, 2024 at 4:20 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Well, it looks like it was un-deprecated in 2019
>> <https://github.com/geoserver/geoserver/commit/9acd9939f6e2452d69432c277b525af3d1f4f500#diff-edeb363841a79844713af33cb2bfa7e1d1e1e7ed348fddb4e8a7b81fdd51L37-L44>
>> but still nobody calls it. For me it's ok if we have a single extension to
>> listen to reloads (GeoServerLifecycleHandler), especially cause
>> implementers just need to supply a spring bean and not manually add the
>> listener to the catalog.
>> Just wondering if someone ever noticed these CatalogListeners
>> implementing `reloaded()` will never be called.
>>
>> git show 9acd9939f6e2452d69432c277b525af3d1f4f500 -- `find . -name
>> CatalogListener.java`
>> commit 9acd9939f6e2452d69432c277b525af3d1f4f500
>> Autho

Re: [Geoserver-devel] is CatalogListener.reloaded() dead code?

[Gabriel Roldan]

Well, it looks like it was un-deprecated in 2019
<https://github.com/geoserver/geoserver/commit/9acd9939f6e2452d69432c277b525af3d1f4f500#diff-edeb363841a79844713af33cb2bfa7e1d1e1e7ed348fddb4e8a7b81fdd51L37-L44>
but still nobody calls it. For me it's ok if we have a single extension to
listen to reloads (GeoServerLifecycleHandler), especially cause
implementers just need to supply a spring bean and not manually add the
listener to the catalog.
Just wondering if someone ever noticed these CatalogListeners implementing
`reloaded()` will never be called.

git show 9acd9939f6e2452d69432c277b525af3d1f4f500 -- `find . -name
CatalogListener.java`
commit 9acd9939f6e2452d69432c277b525af3d1f4f500
Author: Andrea Aime 
Date:   Sun Apr 28 15:14:56 2019 +0200

Deprecated API checkpoint on main, more deprecated API yet to remove

diff --git
a/src/main/src/main/java/org/geoserver/catalog/event/CatalogListener.java
b/src/main/src/main/java/org/geoserver/catalog/event/CatalogListener.java
index 6dba393d702..c3d28df435b 100644
---
a/src/main/src/main/java/org/geoserver/catalog/event/CatalogListener.java
+++
b/src/main/src/main/java/org/geoserver/catalog/event/CatalogListener.java
@@ -34,12 +34,6 @@ public interface CatalogListener {
 /** Handles the event of a post modification to an object in the
catalog. */
 void handlePostModifyEvent(CatalogPostModifyEvent event) throws
CatalogException;

-/**
- * A callback notifying when GeoServer configuration has been reloaded.
- *
- * This method will be removed in recent version as the idea of a
"reload" will not exist.
- *
- * @deprecated.
- */
+/** A callback notifying when GeoServer configuration has been
reloaded. */
 void reloaded();
 }

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Mon, May 20, 2024 at 1:30 AM Jody Garnett  wrote:

> What does happen on catalogue reload? can we restore the event?
>
> --
> Jody Garnett
>
>
> On Sun, May 19, 2024 at 5:27 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hey all,
>>
>> tried to live-test a CatalogListener.reloaded() implementation, turns out
>> I can't find any caller in the codebase:
>>
>> grep "\.reloaded()" -R --include=*.java
>> wms/src/test/java/org/geoserver/wms/capabilities/GetCapabilitiesLegendURLTest.java:
>>((LegendSampleImpl)
>> GeoServerExtensions.bean(LegendSample.class)).reloaded();
>>
>> Is it supposed to be replaced by GeoServerLifecycleHandler.onReload(), or
>> at some point we stopped calling it?
>> There seems to be a couple implementations out there with non-empty
>> bodies:
>> - LayerGroupContainmentCache$CatalogChangeListener
>> - LegendSampleImpl
>> - MimeTypeCacheClearingListener
>> - WFSConfiguration'\s anonymous inner class
>>
>>
>> TIA,
>> gabe
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] is CatalogListener.reloaded() dead code?

[Gabriel Roldan]

Hey all,

tried to live-test a CatalogListener.reloaded() implementation, turns out I
can't find any caller in the codebase:

grep "\.reloaded()" -R --include=*.java
wms/src/test/java/org/geoserver/wms/capabilities/GetCapabilitiesLegendURLTest.java:
   ((LegendSampleImpl)
GeoServerExtensions.bean(LegendSample.class)).reloaded();

Is it supposed to be replaced by GeoServerLifecycleHandler.onReload(), or
at some point we stopped calling it?
There seems to be a couple implementations out there with non-empty bodies:
- LayerGroupContainmentCache$CatalogChangeListener
- LegendSampleImpl
- MimeTypeCacheClearingListener
- WFSConfiguration'\s anonymous inner class


TIA,
gabe
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] Backporting filter parameter fixes for file blobstore

[Gabriel Roldan]

sounds great to me
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Fri, May 10, 2024 at 12:14 PM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi all,
> a month ago this PR that fixes an issue with filter parameters handling in
> GWC file blob storage:
> https://github.com/GeoWebCache/geowebcache/pull/1230
>
> Some context:
>
>- Filter parameters in GWC allow the creation of parallel caches for
>different parameter values (e.g., time, elevation, viewparam, env, anything
>hanging an effect on the tile contents)
>- Given the parameter contents might be long, complex, and not file
>system friendly, all blob storages turn them into a summary string, a SHA1,
>that identifies them (not entirely collision free, but the chance is really
>low)
>- The mapping between the sha1 and the actual set of parameter values
>is stored too. And here is where the difference is, the cloud storages
>store it in the same "folder" where the tiles are put, the file system in a
>single, centralized property file for the layer
>
> The latter is handy, but at the same time, it creates a point of
> contention among many threads/processes, and the file can grow very large
> (think of long time series), exacerbating the problem to the point that
> even just adding a new entry is slow. Add to that a NFS mount, and you have
> all the elements for a horror movie.
>
> The PR simply aligns the file system blobstore practice with the cloud
> storage case, where the file has only one entry, is immutable past
> creation, and if two processes manage to step on each other toas, they
> would still produce the same file content.
>
> And oh, the code is setup so that there is transparent migration of the
> entries from the old to the new storage, so nothing is lost.
>
> Soo... objections to backport to stable/maintenance?
>
> Regards,
>
> Andrea Aime
>
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Pre-proposal discussion, amending community module graduation rules

[Gabriel Roldan]

I like Jody's alternative wording.

I may be mistaken but there seems to be two kinds of community modules.
Those that are in the communityRelease profile and those that aren't.
Here's an idea: for those that are, it'd be good to have a build job that
runs the tests, and they should be required to pass tests to stay in the
communityRelease profile.
For graduation, 40% test coverage seems rather low a requirement?
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Wed, Mar 13, 2024 at 5:41 AM Alessio Fabiani <
alessio.fabi...@geosolutionsgroup.com> wrote:

> Agree, and +1. The proposal makes sense. Also +1 for the Jody statement
> also. Of course a community module should not contain any kind of ad-hoc or
> hard-coded stuff in order to be merged.
>
> On Tue, Mar 12, 2024 at 6:21 PM Jody Garnett 
> wrote:
>
>> Andrea:
>>
>> I am in favour of being less *specific* in these kind of requirements in
>> preference to stating the goal and providing an example.
>>
>> "The module is not site specific and can be configured for use by the
>> general GeoServer community. A community module that already has 3 users
>> would meet this goal; while a community module that has hard coded a domain
>> name would not."
>>
>> (And I will stay on topic)
>> --
>> Jody Garnett
>>
>>
>> On Mar 12, 2024 at 4:19:42 AM, Andrea Aime <
>> andrea.a...@geosolutionsgroup.com> wrote:
>>
>>> Hi all,
>>> I'm starting this conversation to see if/how we can amend the procedures
>>> for graduating a community module a bit.
>>>
>>> For reference, the current procedure is here:
>>>
>>> https://docs.geoserver.org/latest/en/developer/policies/community-modules.html#id2
>>>
>>> In particular, I'm thinking about requirement "1", the module has at
>>> least 3 users.
>>> The reason for the check is a good one, we don't want to clutter the
>>> main code base with modules that are specific to one single user site. At
>>> the same time, this creates a "chicken and egg" problem, because many sites
>>> won't consider using a module until it's supported.
>>>
>>> So, I'd like to keep the intent of requirement 1, but propose a change
>>> in its implementation. 3 usage sites can be one of the options, but can we
>>> also consider a PSC opinion on the matter as a valid alternative? And a PSC
>>> member can provide feedback on the module generality while the graduation
>>> is being voted.
>>>
>>> I know that Jody wants to also talk about point 3 (module being stable,
>>> as a prerequisite, the standards that the module is based on being stable
>>> too), but can we please have a separate thread for that?
>>>
>>> Best regards
>>> Andrea
>>>
>>> ==
>>> GeoServer Professional Services from the experts!
>>>
>>> Visit http://bit.ly/gs-services-us for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions Group
>>> phone: +39 0584 962313
>>>
>>> fax: +39 0584 1660272
>>>
>>> mob:   +39  339 8844549
>>>
>>> https://www.geosolutionsgroup.com/
>>>
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>>
>>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>> precisa che ogni circostanza inerente alla presente email (il suo
>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
>
> Regards,
>
> Alessio Fabiani
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Alessio Fabiani
>
> @alfa7691
> Founder/Technical Lead
>
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  331 6233686
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> 

Re: [Geoserver-devel] Upcoming 2.25-RC Release candidate planning

[Gabriel Roldan]

Hi,

I do want to get involved in the ResourceStore API discussion.

Unfortunately, I'll be on vacation next week, so if you don't mind I
propose we leave it off from this release.

Meanwhile, I'd like to ask Niels to update the PR description with a
(rather succinct) description of the issue and breakdown of the approach.
That helps a lot in reviewing, and going through the very long discussion
on the email list is draining.

TIA,
Gabe
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Fri, Feb 16, 2024 at 4:59 AM Jody Garnett  wrote:

> We are a couple weeks a way from the 2.25-RC and I am aware of a number of
> outstanding pull-requests that are wishing review.
>
>
>- [GEOS-11284] Promote community module "datadir catalog loader" to
>core 
>- Andrea is presently reviewing
>- [GEOS-11050] Refactor Resources and Paths API to support alternative
>
>- Jody (and possibly Gabe) to review
>- If there is anything else please speak up!
>
>
> NOTICE: As per last meeting I volunteered to do this release, checking my
> work calendar I may be doing this a few days early (Feb 28-29).
> --
> Jody Garnett
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GeoServer on Java 21

[Gabriel Roldan]

Hi Andrea,

good idea indeed. Unfortunately, the build won't work out of the box (I
now know you know from comments in another pr).
I've created this draft PR to follow up on this:
https://github.com/geoserver/geoserver/pull/7207
So far `mvn clean install` works for the core modules, will try
-Prelease,communityRelease later, I'd expect some may fail though.

Cheers,
Gabe


On Mon, 16 Oct 2023 at 11:27, Andrea Aime 
wrote:

> Hi all,
> I'm wondering, did anyone try to use GeoServer on Java 21 yet?
>
> I've tried quickly today, because Java 21 has become the default version
> proposed on Windows and saw colleagues stumble on it. As far as I can tell,
> it works, as long as one removes the Marlin renderer integration from the
> startup scripts.
> Regarding this topic, see also the "Time to drop the Marlin renderer
> dependency?" some six months ago, on this same list.
>
> That said, thinking out loud... time to setup Java 21 build jobs, just to
> keep tabs on it?
> (and yes, also upgrade Marlin and change the integration style, so that it
> can possibly work on Java 17 and maybe 21 too).
>
> Cheers
> Andrea
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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

Re: [Geoserver-devel] Add Java 17 JDK to build.geoserver.org?

[Gabriel Roldan]

Hi Torben and Jody,
thanks for the insights, and sorry for the slow turnaround, it caught me on
vacation.

Unfortunately I can't add it myself. I get a "groldan is missing the
Overall/Administer permission" error.

So please add it at your earliest convenience.

TIA,

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Mon, Sep 11, 2023 at 4:45 PM Torben Barsballe 
wrote:

> Hi Gabe,
>
> We should be able to add a Java 17 JDK. Can you access
> https://build.geoserver.org/manage/configureTools/ ?.
> You should be able to add it under "JDK Installations".
>
> If not, I can add it.
>
> Cheers,
> Torben
>
> On Mon, Sep 11, 2023 at 9:15 AM Jody Garnett 
> wrote:
>
>> Gabe:
>>
>> I do not have shell access, we will need to contact GeoSolutions admin I
>> believe.
>>
>> Add it as a topic for tomorrows PSC meeting.
>>
>> Jody
>>
>> On Sun, Sep 10, 2023 at 10:39 PM Gabriel Roldan <
>> gabriel.rol...@camptocamp.com> wrote:
>>
>>> Hi,
>>>
>>> I need to publish a spring-boot:3.x/spring:6.x Java client for GeoServer
>>> ACL.
>>> The problem is there's no Java 17 JDK in build.geoserver.org.
>>>
>>> Is it possible to add one? since that's the only way to publish the
>>> maven artifacts.
>>>
>>> TIA,
>>>
>>> *camptocamp*
>>> INNOVATIVE SOLUTIONS
>>> BY OPEN SOURCE EXPERTS
>>>
>>> *Gabriel Roldán*
>>> Geospatial Developer
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Add Java 17 JDK to build.geoserver.org?

[Gabriel Roldan]

Hi,

I need to publish a spring-boot:3.x/spring:6.x Java client for GeoServer
ACL.
The problem is there's no Java 17 JDK in build.geoserver.org.

Is it possible to add one? since that's the only way to publish the maven
artifacts.

TIA,

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

[Geoserver-devel] [JIRA] (GEOS-11094) Bump org.hsqldb:hsqldb:2.7.1 to 2.7.2

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMDQxYzAxNzUwYjg0NDE1NjllYzAzZmUyYzI3Y2EwZDEiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-11094?atlOrigin=eyJpIjoiMDQxYzAxNzUwYjg0NDE1NjllYzAzZmUyYzI3Y2EwZDEiLCJwIjoiaiJ9
 ) GEOS-11094 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11094?atlOrigin=eyJpIjoiMDQxYzAxNzUwYjg0NDE1NjllYzAzZmUyYzI3Y2EwZDEiLCJwIjoiaiJ9
 ) Bump org.hsqldb:hsqldb:2.7.1 to 2.7.2 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11094?atlOrigin=eyJpIjoiMDQxYzAxNzUwYjg0NDE1NjllYzAzZmUyYzI3Y2EwZDEiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 03/Aug/23 6:04 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

GeoTool’s gt-epsg-hsqldb depends on org.hsqldb:hsqldb:2.7.2 , but GeoServer 
overrides it with 2.7.1

( 
https://osgeo-org.atlassian.net/browse/GEOS-11094#add-comment?atlOrigin=eyJpIjoiMDQxYzAxNzUwYjg0NDE1NjllYzAzZmUyYzI3Y2EwZDEiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-11094#add-comment?atlOrigin=eyJpIjoiMDQxYzAxNzUwYjg0NDE1NjllYzAzZmUyYzI3Y2EwZDEiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- 
sha1:3ea1a2a )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-11090) Use Catalog streaming API in WorkspacePage

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiYTNjNzdmNDMwMTE0NDY3ZTg2MjIxZWZhZGViY2JmZTQiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-11090?atlOrigin=eyJpIjoiYTNjNzdmNDMwMTE0NDY3ZTg2MjIxZWZhZGViY2JmZTQiLCJwIjoiaiJ9
 ) GEOS-11090 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11090?atlOrigin=eyJpIjoiYTNjNzdmNDMwMTE0NDY3ZTg2MjIxZWZhZGViY2JmZTQiLCJwIjoiaiJ9
 ) Use Catalog streaming API in WorkspacePage ( 
https://osgeo-org.atlassian.net/browse/GEOS-11090?atlOrigin=eyJpIjoiYTNjNzdmNDMwMTE0NDY3ZTg2MjIxZWZhZGViY2JmZTQiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Components: web-app Created: 01/Aug/23 6:19 AM Priority: Medium Reporter: 
Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

WorkspacePageProvider loads all workspaces from the catalog several times, for 
size() , fullSize() , and items().

Implement iterator() as done for the other data admin pages to call 
Catalog.count() and Catalog.list(...) instead.

( 
https://osgeo-org.atlassian.net/browse/GEOS-11090#add-comment?atlOrigin=eyJpIjoiYTNjNzdmNDMwMTE0NDY3ZTg2MjIxZWZhZGViY2JmZTQiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-11090#add-comment?atlOrigin=eyJpIjoiYTNjNzdmNDMwMTE0NDY3ZTg2MjIxZWZhZGViY2JmZTQiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- 
sha1:b4f309b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-11089) Performance penalty adding namespaces while loading catalog

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiOTYxYzgzNDBkNDFiNGQ0YmJlN2QwYzgwNGRiODQwMzQiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-11089?atlOrigin=eyJpIjoiOTYxYzgzNDBkNDFiNGQ0YmJlN2QwYzgwNGRiODQwMzQiLCJwIjoiaiJ9
 ) GEOS-11089 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11089?atlOrigin=eyJpIjoiOTYxYzgzNDBkNDFiNGQ0YmJlN2QwYzgwNGRiODQwMzQiLCJwIjoiaiJ9
 ) Performance penalty adding namespaces while loading catalog ( 
https://osgeo-org.atlassian.net/browse/GEOS-11089?atlOrigin=eyJpIjoiOTYxYzgzNDBkNDFiNGQ0YmJlN2QwYzgwNGRiODQwMzQiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Unassigned Created: 31/Jul/23 7:04 PM 
Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

DefaultCatalogFacade.add(Namespace Info) hinders performance, especially during 
startup with many workspaces/namespaces.

The reason is CatalogImpl.add(NamespaceInfo) will validate there's no other 
namespace with the same URI, for which IsolatedCatalogFacade will call 
getNamespacesByURI(String):List , which calls CatalogInfoLookup.list(...) with 
a predicate to filter out the namespaces by uri.

This on itself ends up being heavier and heavier as the number of namespaces 
increase.

The proposed solution is to for the namespaces CatalogInfoLookup to maintain an 
index of NamespaceInfo by URI.

( 
https://osgeo-org.atlassian.net/browse/GEOS-11089#add-comment?atlOrigin=eyJpIjoiOTYxYzgzNDBkNDFiNGQ0YmJlN2QwYzgwNGRiODQwMzQiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-11089#add-comment?atlOrigin=eyJpIjoiOTYxYzgzNDBkNDFiNGQ0YmJlN2QwYzgwNGRiODQwMzQiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- 
sha1:da16c62 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-11088) 30% of startup time spent in XstreamPersister's CRSConverter

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNjA4YTQ3YTlmN2YzNGNmNGI5YzQ5MGEzZTEwMjgyNWUiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-11088?atlOrigin=eyJpIjoiNjA4YTQ3YTlmN2YzNGNmNGI5YzQ5MGEzZTEwMjgyNWUiLCJwIjoiaiJ9
 ) GEOS-11088 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11088?atlOrigin=eyJpIjoiNjA4YTQ3YTlmN2YzNGNmNGI5YzQ5MGEzZTEwMjgyNWUiLCJwIjoiaiJ9
 ) 30% of startup time spent in XstreamPersister's CRSConverter ( 
https://osgeo-org.atlassian.net/browse/GEOS-11088?atlOrigin=eyJpIjoiNjA4YTQ3YTlmN2YzNGNmNGI5YzQ5MGEzZTEwMjgyNWUiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Attachments: image-20230731-145627.png Created: 31/Jul/23 4:59 PM Priority: 
Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

30% of startup time is spent in XstreamPersister$CRSEncoder.fromString() 
(calling CRS.parseWKT(String) )

( https://osgeo-org.atlassian.net/rest/api/3/attachment/content/34054 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-11088#add-comment?atlOrigin=eyJpIjoiNjA4YTQ3YTlmN2YzNGNmNGI5YzQ5MGEzZTEwMjgyNWUiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-11088#add-comment?atlOrigin=eyJpIjoiNjA4YTQ3YTlmN2YzNGNmNGI5YzQ5MGEzZTEwMjgyNWUiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- 
sha1:da16c62 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-11087) Fix IsolatedCatalogFacade unnecessary performance overhead

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiZTU4OTg0NmMyODYyNDI1NjhkMTBlN2I2NDAzNmY5NWYiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-11087?atlOrigin=eyJpIjoiZTU4OTg0NmMyODYyNDI1NjhkMTBlN2I2NDAzNmY5NWYiLCJwIjoiaiJ9
 ) GEOS-11087 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11087?atlOrigin=eyJpIjoiZTU4OTg0NmMyODYyNDI1NjhkMTBlN2I2NDAzNmY5NWYiLCJwIjoiaiJ9
 ) Fix IsolatedCatalogFacade unnecessary performance overhead ( 
https://osgeo-org.atlassian.net/browse/GEOS-11087?atlOrigin=eyJpIjoiZTU4OTg0NmMyODYyNDI1NjhkMTBlN2I2NDAzNmY5NWYiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 31/Jul/23 4:28 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

IsolatedCatalogFacade adds unnecessary overhead:

* when the request is not an OWS request (signaled by Dispatcher.REQUEST.get() 
== null ) , it doesn’t need to filter out anything

* count(Class, Filter) grabs an interator and counts its elements, can be 
avoided if

* list(Class, Filter, Integer, Integer, SortBy...):CloseableIterator builds an 
ArrayList to return its iterator, when it should just filter the provided 
iterator

( 
https://osgeo-org.atlassian.net/browse/GEOS-11087#add-comment?atlOrigin=eyJpIjoiZTU4OTg0NmMyODYyNDI1NjhkMTBlN2I2NDAzNmY5NWYiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-11087#add-comment?atlOrigin=eyJpIjoiZTU4OTg0NmMyODYyNDI1NjhkMTBlN2I2NDAzNmY5NWYiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- 
sha1:da16c62 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] changes to ResourceStore

[Gabriel Roldan]

If "the codebase had drifted away from the intended use over time" I think
it's even more important to stick to the contract and not the other way
around.
As far as I can see, there are two abstractions, ResourceStore and
Resource, the former clearly says
"This abstraction assumes a unix like file system, all paths are relative
and use forward slash  {@code /} as the separator",
the latter "Resource used for configuration storage.".
Only by adhering to this contract, we could provide alternative
implementations.
So if the changes were made to accommodate "common usage" on the specific
case of a filesystem-based ResourceStore
implementation, it should be the other way around, to find out usages that
don't adhere to the spec and fix them.

Concretely, I _think_ the only place where absolute URI's would be
requested to the ResourceStore, is where a data, not configuration,
file, is resolved, expecting the ResourceStore to be smart and resolve
"file:data/roads.shp" relative to the datadir, and "file:/data/roads.shp"
relative to the file system.
Now, in doing so, we're asking the ResourceStore to do what it's not
intended to. The test case Niels mentioned used to check that a leading "/"
had no meaning for the resource store (i.e. /data/roads.shp ==
data/roads.shp), and that was changed to mean the opposite.
So, IMHO, the responsibility of resolving files outside the datadir
shouldn't be on ResourceStore, but on the client code. Something like:

String path = ...
File shp;
if(Paths.isAbsolute(path))
  shp = new File(path);
else
 shp = resourceStore.get(path).file();

As a matter of fact, Resource.file():java.io.File should be deprecated and
eventually removed. Resource is for config contents and
has Resource.in():InputStream and Resource.out():OutputStream.

It is hard enough already to adhere to lax interface contracts (catalog's
default workspace hello) as to keep on making it more and more difficult.

So what do we do? can we get to an agreement that the contract in the
interfaces is mandatory and work from there?

cheers,
On Tue, 4 Jul 2023 at 17:49, Niels Charlier via Geoserver-devel <
geoserver-devel@lists.sourceforge.net> wrote:

> Hello Jody,
>
> Yes, I admit it's my own fault for missing this discussion at the time.
>
> I think it would be a shame to let the codebase further drift away from
> the intended use of the resource store. We have done the work to make the
> entirety of geoserver generic with respect to the implementation of the
> data directory and it is only a minimal effort to keep it this way. Even
> though jdbc store is still a community module and the Redis based geoserver
> project has been discontinued, it has been proven that alternative
> implementations for the data directory work and the jdbc store module is
> actually being used in production successfully.
>
> Now, interestingly, I have discovered that there are contradictions in how
> it works / is documented now.
>
> - I discovered that while 'theoryRootIsAbsolute' test is successful, it is
> actually very misleading. At least on linux, paths starting with '/' *still
> create a file relative to the data directory*!. The only difference is the
> string returned by the path() method. So while the path might seem
> absolute, the file you are accessing is not. So the path() method is
> misleading and in reality the leading slash is still being ignored (again,
> at least on linux).
>
> - Note that the javadoc of ResourceStore still says:
>
> This abstraction assumes a unix like file system, *all paths are relative*
>
> There it says it: all paths are relative for the resourcestore. Absolute
> paths have no meaning or function when it comes to the resource store.
>
> - I think this contradiction could be resolved in two possible ways:
>
> 1) the test 'theoryIsRootSlashIsIgnored' should come back instead of
> 'theoryRootIsAbsolute'. The root slash is ignored and removed from the path.
>
> 2) The resource store throws an exception when you ask for an absolute
> path.
>
> Either way, all absolute paths should be handled *outside of* the
> ResourceStore, for instance by calling Files.asResource(). So problems with
> absolute paths in the rest service should be resolved in the rest service,
> or some other layer that is used by the rest service.
> Kind Regards
> Niels
>
> On 04/07/2023 21:59, Jody Garnett wrote:
>
> Hello Niels,
>
> The PRs for this activity contain extensive discussion.
>
> The fundamental issue was the handling of absolute paths which was done
> differently by different sections of code.  Specifically we found that the
> REST API endpoint was allowing paths *//data* and */data *to both
> reference content in the data directory, rather than treating the first one
> as an absolute path. In response we tightened up the javadocs and added
> test cases including the one you mentioned.
>
> I agree that this goes against the goal of resource store, but the
> codebase had drifted away from the intended use over time.
>
> Now 

[Geoserver-devel] [JIRA] (GEOS-11049) Community module "datadir catalog loader"

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNTZhMGE0ZGUyYzY5NGUyYjk4MGEwZGVhOGQyZTFkZjYiLCJwIjoiaiJ9
 ) / New Feature ( 
https://osgeo-org.atlassian.net/browse/GEOS-11049?atlOrigin=eyJpIjoiNTZhMGE0ZGUyYzY5NGUyYjk4MGEwZGVhOGQyZTFkZjYiLCJwIjoiaiJ9
 ) GEOS-11049 ( 
https://osgeo-org.atlassian.net/browse/GEOS-11049?atlOrigin=eyJpIjoiNTZhMGE0ZGUyYzY5NGUyYjk4MGEwZGVhOGQyZTFkZjYiLCJwIjoiaiJ9
 ) Community module "datadir catalog loader" ( 
https://osgeo-org.atlassian.net/browse/GEOS-11049?atlOrigin=eyJpIjoiNTZhMGE0ZGUyYzY5NGUyYjk4MGEwZGVhOGQyZTFkZjYiLCJwIjoiaiJ9
 )

Issue Type: New Feature Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Components: Community modules Created: 01/Jul/23 4:36 PM Priority: Medium 
Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

There's an optimized data-directory-specific catalog and config loader plugin 
developed under geoserver-cloud's code base that we'd like to contribute 
upstream as a community module.

Its goal is to improve the startup time of GeoServer when configured with a 
data directory that has thousands of layers, stores, etc., and config objects 
such as workspace services and settings.

On my laptop's SSD, running off a cold disk cache, for a data-dir with 100K 
layers over 100 workspaces, the performance improvement is ~8.5 seconds instead 
of ~44.5 seconds, with 2.23.1 as a baseline.

But the most important difference is when you need to load the data dir from a 
shared drive, especially NFS, where it regularly takes over 40 minutes, and 
with this plugin around 4 minutes.

( 
https://osgeo-org.atlassian.net/browse/GEOS-11049#add-comment?atlOrigin=eyJpIjoiNTZhMGE0ZGUyYzY5NGUyYjk4MGEwZGVhOGQyZTFkZjYiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-11049#add-comment?atlOrigin=eyJpIjoiNTZhMGE0ZGUyYzY5NGUyYjk4MGEwZGVhOGQyZTFkZjYiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100227- 
sha1:9e449c4 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] New community module "datadir-catalog-loader"

[Gabriel Roldan]

Hi list,

There's an optimized data-directory specific catalog and config loader
plugin developed under geoserver-cloud's code base that we'd like to
contribute upstream as a community module.

Its goal is to improve the startup time of GeoServer when configured with a
data directory that has thousands of layers, stores, etc. and config
objects such as workspace services and settings.

On my laptop's SSD, running off a cold disk cache, for a datadir with 100K
layers over 100 workspaces, the performance improvement is ~8.5 seconds
instead of ~44.5 seconds, with 2.23.1 as baseline.

But the most important difference is when you need to load the datadir from
a shared drive, especially NFS, where it regularly takes over 40 minutes,
and with this plugin around 4 minutes.

Hence I'm asking the PSC for permission to push this plugin under
community/datadir-catalog-loader

Here's a PR for your reference.

Cheers,

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] New community module "datadir-catalog-loader"

[Gabriel Roldan]

Thanks Andrea.
Sorry guys if eventually an exactly equal message arrives from
my @camptocamp account, I initially sent it from there but it wasn't
coming through for some reason.

On Sat, 1 Jul 2023 at 11:27, Andrea Aime 
wrote:

> +1, thanks for sharing!
>
> Cheers
> Andrea
>
> On Sat, Jul 1, 2023 at 4:25 PM Gabriel Roldan 
> wrote:
>
>> Hi, list,
>>
>> There's an optimized data-directory-specific catalog and config loader
>> plugin developed under geoserver-cloud's code base that we'd like to
>> contribute upstream as a community module.
>>
>> Its goal is to improve the startup time of GeoServer when configured with
>> a data directory that has thousands of layers, stores, etc., and config
>> objects such as workspace services and settings.
>>
>> On my laptop's SSD, running off a cold disk cache, for a data-dir with
>> 100K layers over 100 workspaces, the performance improvement is ~8.5
>> seconds instead of ~44.5 seconds, with 2.23.1 as a baseline.
>>
>> But the most important difference is when you need to load the data dir
>> from a shared drive, especially NFS, where it regularly takes over 40
>> minutes, and with this plugin around 4 minutes.
>>
>> Hence I'm asking the PSC for permission to push this plugin under
>> community/datadir-catalog-loader
>>
>> Here's a PR for your reference.
>>
>> Cheers,
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> --
>> Gabriel Roldán
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>


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

[Geoserver-devel] New community module "datadir-catalog-loader"

[Gabriel Roldan]

Hi, list,

There's an optimized data-directory-specific catalog and config loader
plugin developed under geoserver-cloud's code base that we'd like to
contribute upstream as a community module.

Its goal is to improve the startup time of GeoServer when configured with a
data directory that has thousands of layers, stores, etc., and config
objects such as workspace services and settings.

On my laptop's SSD, running off a cold disk cache, for a data-dir with 100K
layers over 100 workspaces, the performance improvement is ~8.5 seconds
instead of ~44.5 seconds, with 2.23.1 as a baseline.

But the most important difference is when you need to load the data dir
from a shared drive, especially NFS, where it regularly takes over 40
minutes, and with this plugin around 4 minutes.

Hence I'm asking the PSC for permission to push this plugin under
community/datadir-catalog-loader

Here's a PR for your reference.

Cheers,

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer

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

Re: [Geoserver-devel] Jenkins build job to publish GeoServer ACL maven artifacts

[Gabriel Roldan]

Got it. After a couple failed attempts got it working. Thanks a lot.


El El vie, 21 de abr. de 2023 a la(s) 14:49, Jody Garnett <
jody.garn...@gmail.com> escribió:

> Gabe:
>
> Please give it a go setting up jobs on build.geoserver.org - you can use
> the existing jobs as an example of how to work with the credentials?
>
> If you look at the existing jobs that deploy they are configured with a
> maven settings.xml file.
> --
> Jody Garnett
>
>
> On Fri, Apr 21, 2023 at 10:24 AM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hey Jody,
>>
>> For the GeoServer ACL we have github CI build jobs [1], but IIRC you
>> mentioned you didn't want maven repo credentials spread over anything but
>> build.geoserver.org.
>>
>> It looks like I do have permissions to create new build jobs, but I'd
>> need some assistance in setting up the credentials to publish the maven
>> artifacts.
>>
>> How do you think we should proceed?
>>
>> TIA,
>> Gabe
>>
>> [1] https://github.com/geoserver/geoserver-acl/actions
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> --
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] GeoSever ACL: is an OsGeo Corporate Contribution Agreement still needed?

[Gabriel Roldan]

what can I say other than sorry for wasting your time...
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Fri, Apr 21, 2023 at 2:46 PM Jody Garnett  wrote:

> I moved important things off the wiki where they could be edited by anyone
> to the website: https://www.osgeo.org/about/licenses/
>
> I believe our CONTIRBUTING.md
> <https://github.com/geoserver/geoserver/blob/main/CONTRIBUTING.md> file
> links to the correct location? Yes it does:
> https://www.osgeo.org/resources/individual-contributor-license/
>
> Looking at the page your found it was from 2006:
> https://wiki.osgeo.org/w/index.php?title=Corporate_Contributor_License_Agreement_(CCLA)=history
>
>
> --
> Jody Garnett
>
>
> On Fri, Apr 21, 2023 at 10:16 AM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi PSC,
>>
>> In looking for the template document from OsGeo to send a "Software Grant
>> and Corporate Contributor License Agreement" for the GeoSever ACL
>> project,
>> I found this wiki page [1], linking to the Corporate Contributor License
>> Agreement (CCLA)
>> <https://wiki.osgeo.org/wiki/Corporate_Contributor_License_Agreement_(CCLA)>
>>
>> which only says "Content deprecated."
>>
>> So I'm confused, may I just not be looking at the right place, or do we
>> really not
>> need to sign such a document anymore?
>>
>>
>> [1] https://wiki.osgeo.org/wiki/Contributor_Agreement
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Jenkins build job to publish GeoServer ACL maven artifacts

[Gabriel Roldan]

Hey Jody,

For the GeoServer ACL we have github CI build jobs [1], but IIRC you
mentioned you didn't want maven repo credentials spread over anything but
build.geoserver.org.

It looks like I do have permissions to create new build jobs, but I'd need
some assistance in setting up the credentials to publish the maven
artifacts.

How do you think we should proceed?

TIA,
Gabe

[1] https://github.com/geoserver/geoserver-acl/actions

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

[Geoserver-devel] GeoSever ACL: is an OsGeo Corporate Contribution Agreement still needed?

[Gabriel Roldan]

Hi PSC,

In looking for the template document from OsGeo to send a "Software Grant
and Corporate Contributor License Agreement" for the GeoSever ACL project,
I found this wiki page [1], linking to the Corporate Contributor License
Agreement (CCLA)


which only says "Content deprecated."

So I'm confused, may I just not be looking at the right place, or do we
really not
need to sign such a document anymore?


[1] https://wiki.osgeo.org/wiki/Contributor_Agreement

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] GSIP-217 geoserver/geoserver-acl repository

[Gabriel Roldan]

Awesome, thanks!
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Developer



On Fri, Apr 7, 2023 at 3:23 PM Jody Garnett  wrote:

> Here is the new repository: https://github.com/geoserver/geoserver-acl
>
> Gabe you are setup as admin.
> --
> Jody Garnett
>
>
> On Fri, Apr 7, 2023 at 11:16 AM Jody Garnett 
> wrote:
>
>> Sure Gabe; happy to do so - hold on.
>> --
>> Jody Garnett
>>
>>
>> On Fri, Apr 7, 2023 at 9:36 AM Gabriel Roldan <
>> gabriel.rol...@camptocamp.com> wrote:
>>
>>> Hey guys,
>>>
>>> Can someone with admin access to the geoserver github org create
>>> the geoserver/geoserver-acl repository and make me an admin, so we can
>>> proceed with GSIP-217?
>>>
>>> TIA,
>>> *camptocamp*
>>> INNOVATIVE SOLUTIONS
>>> BY OPEN SOURCE EXPERTS
>>>
>>> *Gabriel Roldán*
>>> Geospatial Developer
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] GSIP-217 geoserver/geoserver-acl repository

[Gabriel Roldan]

Hey guys,

Can someone with admin access to the geoserver github org create
the geoserver/geoserver-acl repository and make me an admin, so we can
proceed with GSIP-217?

TIA,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

Re: [Geoserver-devel] GeoFence/ACL related Rule model/evaluation question

[Gabriel Roldan]

Hey Emanuele, thanks for looking into this.

Thinking about your analysis I still can't see why you
couldn't set up the exact same rule set, maybe there's
something not clear in my explanation. Updated the graphics
to represent restrictions with notes to avoid confusion.
Maybe LayerRule should extend AllowRule directly and be a
sibling of LimitRule. That'd be a better approximation to the
current model where class hierarchy only enforces the semantics.
Then I guess given the case it'd boil down to whether the merge
process respects the current algorithm.

In any case I don't want to borrow more time from you for this,
thanks again for looking into it. I might bother again when/if I
decide to move forward, but for the time being there's enough
on my plate, I just didn't want to lose that train of thought.

Cheers,
Gabriel
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer



On Thu, Mar 30, 2023 at 7:48 AM Emanuele Tajariol <
emanuele.tajar...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
>
> I guess that with your model you are losing some flexibility wrt GeoFence:
> Fact is, the LIMIT and ALLOW rules may have different matching scopes,
> Just one example: let's say, you have a layer L1 that needs to be limited
> to area A1 for everyone except for group G1
> In GeoFence you'll create these rules with a high priority, such as for
> instance
>
> - Rule 10: Layer L1, Grant: LIMIT, Area A1
> - Rule >10: Group G1, Layer L1, Grant: ALLOW, Area whole world
> .. then you can have other rules totally limiting the access to layer L1
> or whatever
>
> With your semantic change, you'll have to repeat Rule 10 for each
> group/user in your rulebase.
> This means that, for each group you create, you *need to remember* that
> layer L1 requires area limitation (and then create the related rule).
>
>Cheers,
>Emanuele
>
>
>
>
> On Wed, Mar 29, 2023 at 9:25 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hey there,
>>
>> In relation to how GeoFence/ACL need to define and evaluate data access
>> rules, there's something that's been itching on my neck. I tried to
>> summarize here:
>> https://github.com/camptocamp/geoserver-acl/issues/1
>>
>> It'd be great if you guys can give it a read and spot some fundamental
>> thing I might be missing?
>>
>> TIA!
>> Gabe
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldan*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
> Regards,
> Emanuele Tajariol
> ==
> GeoServer Professional Services from the experts!
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Emanuele Tajariol
> Technical Lead
>
> GeoSolutions Group
> mobile: +39 347 7895230
> office: +39 0584 962313
> fax:  +39 0584 1660272
>
> https://www.geosolutionsgroup.com/
> http://twitter.com/geosolutions_it
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] GeoFence/ACL related Rule model/evaluation question

[Gabriel Roldan]

Hey there,

In relation to how GeoFence/ACL need to define and evaluate data access
rules, there's something that's been itching on my neck. I tried to
summarize here:
https://github.com/camptocamp/geoserver-acl/issues/1

It'd be great if you guys can give it a read and spot some fundamental
thing I might be missing?

TIA!
Gabe

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP-217 Sibling repository for GeoServer ACL project

[Gabriel Roldan]

Thanks everyone for the discussion and consideration for this proposal.

Since all the PSC members casted their vote, I've transitioned the proposal
to in-progress,
and created this JIRA ticket to track progress:
https://osgeo-org.atlassian.net/browse/GEOS-10913

It contains subtasks for the identified steps to completion.

Cheers,
Gabe
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer



On Tue, Mar 28, 2023 at 1:52 PM Torben Barsballe 
wrote:

> After catching up on the background of 216 along with this proposal, the
> approach makes sense to me.
> One piece I didn't see covered is build/release infrastructure for the new
> project - since it is now independent from geofence I assume it will be its
> own group on jenkins, but we can deal with that when we get there.
>
> +1
>
> Cheers,
> Torben
>
> On Tue, Mar 21, 2023 at 6:23 AM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi all,
>>
>> as discussed in the "GSIP-216 GeoFence 4.0.x" email thread, I've created
>> a new GSIP to request hosting the GeoFence fork, called GeoServer ACL, as a
>> sibling project to GeoServer, GeoFence, and GeoServer Cloud, under the
>> /geoserver Github organization.
>>
>> Please see https://github.com/geoserver/geoserver/wiki/GSIP-217 for
>> details, comment back and vote.
>>
>> Best regards,
>> Gabriel.
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldan*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10917) To transfer ownership of the GeoServer ACL project to OsGeo

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiY2UxZDkwMzc4MjY1NGRhY2ExMTJjNjBjMjhlOTA4MTgiLCJwIjoiaiJ9
 ) / Sub-task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10917?atlOrigin=eyJpIjoiY2UxZDkwMzc4MjY1NGRhY2ExMTJjNjBjMjhlOTA4MTgiLCJwIjoiaiJ9
 ) GEOS-10917 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10917?atlOrigin=eyJpIjoiY2UxZDkwMzc4MjY1NGRhY2ExMTJjNjBjMjhlOTA4MTgiLCJwIjoiaiJ9
 ) To transfer ownership of the GeoServer ACL project to OsGeo ( 
https://osgeo-org.atlassian.net/browse/GEOS-10917?atlOrigin=eyJpIjoiY2UxZDkwMzc4MjY1NGRhY2ExMTJjNjBjMjhlOTA4MTgiLCJwIjoiaiJ9
 )

Issue Type: Sub-task Assignee: Unassigned Created: 29/Mar/23 6:23 PM Priority: 
Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-10917#add-comment?atlOrigin=eyJpIjoiY2UxZDkwMzc4MjY1NGRhY2ExMTJjNjBjMjhlOTA4MTgiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10917#add-comment?atlOrigin=eyJpIjoiY2UxZDkwMzc4MjY1NGRhY2ExMTJjNjBjMjhlOTA4MTgiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100219- 
sha1:6a6077b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10916) Create Jenkins build job to publish GeoServer ACL maven artifacts

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNmJlNzNiN2NlNjE4NGQ1ZDkzNTJhODk3OTExNjA2MjAiLCJwIjoiaiJ9
 ) / Sub-task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10916?atlOrigin=eyJpIjoiNmJlNzNiN2NlNjE4NGQ1ZDkzNTJhODk3OTExNjA2MjAiLCJwIjoiaiJ9
 ) GEOS-10916 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10916?atlOrigin=eyJpIjoiNmJlNzNiN2NlNjE4NGQ1ZDkzNTJhODk3OTExNjA2MjAiLCJwIjoiaiJ9
 ) Create Jenkins build job to publish GeoServer ACL maven artifacts ( 
https://osgeo-org.atlassian.net/browse/GEOS-10916?atlOrigin=eyJpIjoiNmJlNzNiN2NlNjE4NGQ1ZDkzNTJhODk3OTExNjA2MjAiLCJwIjoiaiJ9
 )

Issue Type: Sub-task Assignee: Unassigned Created: 29/Mar/23 6:22 PM Priority: 
Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-10916#add-comment?atlOrigin=eyJpIjoiNmJlNzNiN2NlNjE4NGQ1ZDkzNTJhODk3OTExNjA2MjAiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10916#add-comment?atlOrigin=eyJpIjoiNmJlNzNiN2NlNjE4NGQ1ZDkzNTJhODk3OTExNjA2MjAiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100219- 
sha1:6a6077b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10915) Create a GeoServer Community Module for a plugin that integrates GeoServer with the GeoServer ACL service.

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMmM2NWMzMzFiZGM3NDI5ZWEzYmFlZWQ5NmYxYzE2ZmQiLCJwIjoiaiJ9
 ) / Sub-task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10915?atlOrigin=eyJpIjoiMmM2NWMzMzFiZGM3NDI5ZWEzYmFlZWQ5NmYxYzE2ZmQiLCJwIjoiaiJ9
 ) GEOS-10915 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10915?atlOrigin=eyJpIjoiMmM2NWMzMzFiZGM3NDI5ZWEzYmFlZWQ5NmYxYzE2ZmQiLCJwIjoiaiJ9
 ) Create a GeoServer Community Module for a plugin that integrates GeoServer 
with the GeoServer ACL service. ( 
https://osgeo-org.atlassian.net/browse/GEOS-10915?atlOrigin=eyJpIjoiMmM2NWMzMzFiZGM3NDI5ZWEzYmFlZWQ5NmYxYzE2ZmQiLCJwIjoiaiJ9
 )

Issue Type: Sub-task Assignee: Unassigned Created: 29/Mar/23 6:22 PM Priority: 
Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-10915#add-comment?atlOrigin=eyJpIjoiMmM2NWMzMzFiZGM3NDI5ZWEzYmFlZWQ5NmYxYzE2ZmQiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10915#add-comment?atlOrigin=eyJpIjoiMmM2NWMzMzFiZGM3NDI5ZWEzYmFlZWQ5NmYxYzE2ZmQiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100219- 
sha1:6a6077b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10914) Create github geoserver/geoserver-acl repository

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMDRhMGFkY2FhYTFhNDM3NGI0MjE0NDhmMjA5NGNmYWUiLCJwIjoiaiJ9
 ) / Sub-task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10914?atlOrigin=eyJpIjoiMDRhMGFkY2FhYTFhNDM3NGI0MjE0NDhmMjA5NGNmYWUiLCJwIjoiaiJ9
 ) GEOS-10914 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10914?atlOrigin=eyJpIjoiMDRhMGFkY2FhYTFhNDM3NGI0MjE0NDhmMjA5NGNmYWUiLCJwIjoiaiJ9
 ) Create github geoserver/geoserver-acl repository ( 
https://osgeo-org.atlassian.net/browse/GEOS-10914?atlOrigin=eyJpIjoiMDRhMGFkY2FhYTFhNDM3NGI0MjE0NDhmMjA5NGNmYWUiLCJwIjoiaiJ9
 )

Issue Type: Sub-task Assignee: Unassigned Created: 29/Mar/23 6:21 PM Priority: 
Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-10914#add-comment?atlOrigin=eyJpIjoiMDRhMGFkY2FhYTFhNDM3NGI0MjE0NDhmMjA5NGNmYWUiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10914#add-comment?atlOrigin=eyJpIjoiMDRhMGFkY2FhYTFhNDM3NGI0MjE0NDhmMjA5NGNmYWUiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100219- 
sha1:6a6077b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10913) [GSIP 217] GeoServer ACL project

[Gabriel Roldan (JIRA) via Geoserver-devel]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiM2I5MmQ3NTVmYTIwNDk3NWEyMjQwNDg3NzRhNWJmNTciLCJwIjoiaiJ9
 ) / New Feature ( 
https://osgeo-org.atlassian.net/browse/GEOS-10913?atlOrigin=eyJpIjoiM2I5MmQ3NTVmYTIwNDk3NWEyMjQwNDg3NzRhNWJmNTciLCJwIjoiaiJ9
 ) GEOS-10913 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10913?atlOrigin=eyJpIjoiM2I5MmQ3NTVmYTIwNDk3NWEyMjQwNDg3NzRhNWJmNTciLCJwIjoiaiJ9
 ) [GSIP 217] GeoServer ACL project ( 
https://osgeo-org.atlassian.net/browse/GEOS-10913?atlOrigin=eyJpIjoiM2I5MmQ3NTVmYTIwNDk3NWEyMjQwNDg3NzRhNWJmNTciLCJwIjoiaiJ9
 )

Issue Type: New Feature Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 29/Mar/23 6:16 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

Proposal: https://github.com/geoserver/geoserver/wiki/GSIP-217

GeoServer ACL is an advanced authorization system for GeoServer ( 
https://geoserver.org/ ).

It consists of an independent application service that manages access rules, 
and a GeoServer plugin that requests authorization limits on a per-request 
basis.

As an administrator you'll use GeoServer ACL to define rules that grant or deny 
access to published resources based on service request properties such user 
credentials, the type of OWS service, and layers being requested.

These rules can be as open as to grant or deny access to whole GeoServer 
workspaces, or as granular as to specify which geographical areas and layer 
attributes to allow a specific user or user group to see.

As a user you'll perform requests to GeoServer such as WMS GetMap or WFS 
GetFeatures, and the ACL-based authorization engine will limit the visibility 
of the resources and contents of the responses to those matching the rules that 
apply to the request properties and the authenticated user credentials.

GeoServer ACL is not an authentication provider. It's an authorization manager 
that will use the authenticated user credentials, whether they come from Basic 
HTTP, OAuth2/OpenID Connect, or whatever authentication mechanism GeoServer is 
using, to resolve the access rules that apply to each particular request.

GeoServer ACL is Open Source, born as a fork ( 
https://en.wikipedia.org/wiki/Fork_%28software_development%29 ) of GeoFence ( 
https://github.com/geoserver/geofence ). As such, it follows the same logic to 
define data access and administrative access rules. So if you're familiar with 
GeoFence, it'll be easy to reason about GeoServer ACL.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10913#add-comment?atlOrigin=eyJpIjoiM2I5MmQ3NTVmYTIwNDk3NWEyMjQwNDg3NzRhNWJmNTciLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10913#add-comment?atlOrigin=eyJpIjoiM2I5MmQ3NTVmYTIwNDk3NWEyMjQwNDg3NzRhNWJmNTciLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100219- 
sha1:6a6077b )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP-217 Sibling repository for GeoServer ACL project

[Gabriel Roldan]

Thank you all.

Question, shall we wait for the 10 days grace period for all members to
vote or is it time to move it from "under discussion" to "in progress"?

TIA,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer



On Mon, Mar 27, 2023 at 5:37 AM Alessio Fabiani <
alessio.fabi...@geosolutionsgroup.com> wrote:

> +0
>
> On Fri, Mar 24, 2023 at 11:16 AM Nuno Oliveira <
> nuno.olive...@geosolutionsgroup.com> wrote:
>
>> +1
>>
>> On Thu, Mar 23, 2023 at 6:59 PM Ian Turton  wrote:
>>
>>> +1
>>>
>>> On Tue, 21 Mar 2023, 13:23 Gabriel Roldan, <
>>> gabriel.rol...@camptocamp.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> as discussed in the "GSIP-216 GeoFence 4.0.x" email thread, I've
>>>> created a new GSIP to request hosting the GeoFence fork, called GeoServer
>>>> ACL, as a sibling project to GeoServer, GeoFence, and GeoServer Cloud,
>>>> under the /geoserver Github organization.
>>>>
>>>> Please see https://github.com/geoserver/geoserver/wiki/GSIP-217 for
>>>> details, comment back and vote.
>>>>
>>>> Best regards,
>>>> Gabriel.
>>>> *camptocamp*
>>>> INNOVATIVE SOLUTIONS
>>>> BY OPEN SOURCE EXPERTS
>>>>
>>>> *Gabriel Roldan*
>>>> Geospatial Developer
>>>>
>>>> ___
>>>> Geoserver-devel mailing list
>>>> Geoserver-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>>
>> --
>>
>> Regards,
>>
>> Nuno Oliveira
>>
>> ==
>> GeoServer Professional Services from the experts!
>>
>> Visit http://bit.ly/gs-services-us for more information.
>> ==
>>
>> Nuno Miguel Carvalho Oliveira
>> @nmcoliveira
>> Technical Lead / Project Manager
>>
>>
>> GeoSolutions Group
>> phone: +39 0584 962313
>> fax:  +39 0584 1660272
>>
>> https://www.geosolutionsgroup.com/
>> http://twitter.com/geosolutions_it
>> ---
>>
>>
>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>> precisa che ogni circostanza inerente alla presente email (il suo
>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>
>> This email is intended only for the person or entity to which it is
>> addressed and may contain information that is privileged, confidential or
>> otherwise protected from disclosure. We remind that - as provided by
>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>> e-mail or the information herein by anyone other than the intended
>> recipient is prohibited. If you have received this email by mistake, please
>> notify us immediately by telephone or e-mail.
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
>
> Regards,
>
> Alessio Fabiani
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Alessio Fabiani
>
> @alfa7691
> Founder/Technical Lead
>
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  331 6233686
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i desti

Re: [Geoserver-devel] GSIP-217 Sibling repository for GeoServer ACL project

[Gabriel Roldan]

The proposal is updated specifying the versioning approach.
Is there anything else to discuss or can we proceed to voting?

TIA,

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer



On Wed, Mar 22, 2023 at 5:55 AM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
> seeing the GeoFence experience, I agree with you, the two code bases will
> likely evolve at different speeds
> and trying to bind them together on the same release cycle is likely going
> to be a lot of overhead for little or no gain.
>
> Cheers
> Andrea
>
> On Tue, Mar 21, 2023 at 7:35 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi Jody,
>>
>> On Tue, Mar 21, 2023 at 1:06 PM Jody Garnett 
>> wrote:
>>
>>> Your proposal is straightforward and to the point, some feedback for
>>> discussion:
>>>
>>> - I would title the proposal "GeoServer ACL project" (as the important
>>> part is a new project; rather than the repository where it is located).
>>>
>> Done. Good advice.
>>
>>
>>> - One thing I would like addressed in the proposal is indicating how to
>>> keep the project in sync with the geoserver update cycle? I do not wish to
>>> be in the situation where an "official" geoserver project is running
>>> against an unsupported version of geoserver.
>>>
>>  I've been thinking deeply about this, follow up below.
>>
>> - The proposal covers publishing maven artifacts which would be done from
>>> build.geoserver.org (as I do not wish to see credentials scattered
>>> across systems).
>>>
>> Sounds good to me.
>>
>>
>>> Suggest that "GeoServer ACL" main branch track GeoServer main branch in
>>> order to stay in sync and releasable? Taking the geoserver acl client
>>> community module to an extension would also meet this goal.
>>>
>>
>> My concern goes beyond version matching.
>> For the plugin, as a community module, and at least until it becomes an
>> extension, the chances
>> to get a good test coverage from the CI builds are very few.
>> Besides compatibility with the server part API, concerns are limited to
>> the stability of GeoServer's ResourceAccessManager interface and the Wicket
>> libraries.
>>
>> For the server part, the important thing is the REST API
>> version/compatibility with the plugin, may it evolve over time.
>>
>> Making GeoServer ACL's version follow GeoServer's main branch version
>> doesn't make a lot of sense, as we'd either be forced to release new
>> versions that have no changes, or be unable to, or forced to do additional
>> work, if a new GeoServer ACL version is released and it needs to be
>> backported to stable geoserver versions.
>>
>> If both the plugin and the server stay on the same git repository, it's
>> easier to ensure they stay compatible, as the CI build can run the
>> necessary integration tests, and avoid situations like GeoFence's plugin
>> (not embedded) where integration tests are never run, and I couldn't make
>> them pass by setting up a standalone instance as indicated in the tests
>> comments.
>>
>> So, being a separate product, having its own life cycle make the most
>> sense, and moreover, the CI builds could run plugin integration tests
>> against several geoserver versions for a single GeoServer ACL version. e.g.
>> mvn verify -Dgs.version=2.24-SNAPSHOT
>> mvn verify -Dgs.version=2.23.0
>> mvn verify -Dgs.version=2.22.2
>>
>> Then the GeoServer plugin's community module itself could be a
>> practically empty jar with pure dependencies, on a specific gs-acl version.
>>
>> To exemplify, gs-acl 1.0 is released, the geoserver community module
>> depends on gs-acl-plugin:1.0 for the main branch, and all the stable
>> branches.
>>
>> When gs-acl 1.1 is released, we change the dependency of geoserver's main
>> branch community module to gs-acl-plugin:1.1.
>>
>>  Gabe
>>
>>>
>>> --
>>> Jody Garnett
>>>
>>>
>>> On Tue, Mar 21, 2023 at 6:23 AM Gabriel Roldan <
>>> gabriel.rol...@camptocamp.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> as discussed in the "GSIP-216 GeoFence 4.0.x" email thread, I've
>>>> created a new GSIP to request hosting the GeoFence fork, called GeoServer
>>>> ACL, as a sibling project to GeoServer, GeoFence, and GeoServer Cloud,
>>>> under the /geoserver Githu

Re: [Geoserver-devel] GSIP-217 Sibling repository for GeoServer ACL project

[Gabriel Roldan]

Hi Jody,

On Tue, Mar 21, 2023 at 1:06 PM Jody Garnett  wrote:

> Your proposal is straightforward and to the point, some feedback for
> discussion:
>
> - I would title the proposal "GeoServer ACL project" (as the important
> part is a new project; rather than the repository where it is located).
>
Done. Good advice.


> - One thing I would like addressed in the proposal is indicating how to
> keep the project in sync with the geoserver update cycle? I do not wish to
> be in the situation where an "official" geoserver project is running
> against an unsupported version of geoserver.
>
 I've been thinking deeply about this, follow up below.

- The proposal covers publishing maven artifacts which would be done from
> build.geoserver.org (as I do not wish to see credentials scattered across
> systems).
>
Sounds good to me.


> Suggest that "GeoServer ACL" main branch track GeoServer main branch in
> order to stay in sync and releasable? Taking the geoserver acl client
> community module to an extension would also meet this goal.
>

My concern goes beyond version matching.
For the plugin, as a community module, and at least until it becomes an
extension, the chances
to get a good test coverage from the CI builds are very few.
Besides compatibility with the server part API, concerns are limited to the
stability of GeoServer's ResourceAccessManager interface and the Wicket
libraries.

For the server part, the important thing is the REST API
version/compatibility with the plugin, may it evolve over time.

Making GeoServer ACL's version follow GeoServer's main branch version
doesn't make a lot of sense, as we'd either be forced to release new
versions that have no changes, or be unable to, or forced to do additional
work, if a new GeoServer ACL version is released and it needs to be
backported to stable geoserver versions.

If both the plugin and the server stay on the same git repository, it's
easier to ensure they stay compatible, as the CI build can run the
necessary integration tests, and avoid situations like GeoFence's plugin
(not embedded) where integration tests are never run, and I couldn't make
them pass by setting up a standalone instance as indicated in the tests
comments.

So, being a separate product, having its own life cycle make the most
sense, and moreover, the CI builds could run plugin integration tests
against several geoserver versions for a single GeoServer ACL version. e.g.
mvn verify -Dgs.version=2.24-SNAPSHOT
mvn verify -Dgs.version=2.23.0
mvn verify -Dgs.version=2.22.2

Then the GeoServer plugin's community module itself could be a practically
empty jar with pure dependencies, on a specific gs-acl version.

To exemplify, gs-acl 1.0 is released, the geoserver community module
depends on gs-acl-plugin:1.0 for the main branch, and all the stable
branches.

When gs-acl 1.1 is released, we change the dependency of geoserver's main
branch community module to gs-acl-plugin:1.1.

 Gabe

>
> --
> Jody Garnett
>
>
> On Tue, Mar 21, 2023 at 6:23 AM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi all,
>>
>> as discussed in the "GSIP-216 GeoFence 4.0.x" email thread, I've created
>> a new GSIP to request hosting the GeoFence fork, called GeoServer ACL, as a
>> sibling project to GeoServer, GeoFence, and GeoServer Cloud, under the
>> /geoserver Github organization.
>>
>> Please see https://github.com/geoserver/geoserver/wiki/GSIP-217 for
>> details, comment back and vote.
>>
>> Best regards,
>> Gabriel.
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldan*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] GSIP-217 Sibling repository for GeoServer ACL project

[Gabriel Roldan]

Hi all,

as discussed in the "GSIP-216 GeoFence 4.0.x" email thread, I've created a
new GSIP to request hosting the GeoFence fork, called GeoServer ACL, as a
sibling project to GeoServer, GeoFence, and GeoServer Cloud, under the
/geoserver Github organization.

Please see https://github.com/geoserver/geoserver/wiki/GSIP-217 for
details, comment back and vote.

Best regards,
Gabriel.
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP-216 GeoFence 4.0.x

[Gabriel Roldan]

Hi Andrea, Emanuele, and all.

Thanks for this counter-proposal. It makes a lot of sense, and at
Camptocamp we just met and decided it's a good way forward.

The project will be called GeoServer ACL, as in Access Control List.

It will have a somewhat more limited scope than GeoFence, at least
initially,
focusing only on a separate service, not an embedded engine.

Therefore, we need to fine tune a couple aspects.

First and foremost, we need a home for it. It could be as part of
geoserver-cloud's codebase,
but it'd be so much better if we can be granted a /geoserver/geoserver-acl
github repository.

Additionally we'll need to be able to deploy artifacts to maven, so the
community
module can depend on them.

Do you think those two requests are acceptable? How can we proceed? is a
GSIP
required to create a sibling project under github's /geoserver organization?

Best regards,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldan*
Geospatial Developer



On Mon, Mar 13, 2023 at 12:14 PM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
> I’m going to start briefly and do what I haven’t done in ages: cast a -1
> on the proposal, but with an alternative proposal that will allow you to
> retain all your existing work.
>
> Our community has had, over the years, a strong “talk first” policy. It
> means that one should discuss the design of a major change before doing
> actual work. This has precedent, for example it’s what I did in 2013, when
> I proposed to rewrite the CSS styling engine in Java
> <https://sourceforge.net/p/geoserver/mailman/geoserver-devel/thread/CA%2BnxMTvgAPO5rno80eF47%2BFmcJqeFPRSUL7Suf63k%3DSWEeU%3DZA%40mail.gmail.com/#msg30912716>
> (hard lesson learned there).
>
> Another bit that is quite relevant, is who is in control of the module:
> the PSC is the maintainer of all core modules, but extensions modules have
> a dedicated maintainer that controls the module. In this case, that’s
> Emanuele. While for a situation like this it’s great to have a document
> that details the proposed changes, I believe the PSC role is mostly a
> consultation. The rules are not clear here, I’m open to discussion.
>
> There are also practical aspects that make this rewrite a no go; they are
> not technical, but relate to pre-existing knowledge, availability of time
> and money. Maintenance of a module requires few things these days: being
> ready to review changes made by third parties, evaluate bug reports, and
> answer questions on the user list, on a “as time allows” basis. This can be
> done leveraging knowledge of how the module works.
>
> The fork is reshuffling the entire code base, and introducing a number of
> libraries that are not part of the existing GeoServer dependencies. Picking
> up all these new libraries is problematic for the community at large,
> because it increases the number of bits the developers have to be familiar
> with, and makes the review of changes even harder, because one would have
> to get up to speed with them before even starting to look at the code.
>
> Even assuming in blind faith that we could catch up later, it would still
> mean we have no way to review the changes in the short term (too much
> effort combined required to go and learn what we need, and then review the
> full rewrite).
> So, where to go from here? Where you are going, we simply cannot follow.
>
> We kindly ask you to retain all your work, and give it a different name:
> let’s call it GING for now (GING Is Not GeoFence).
> The following points are very important for us:
>
>- GING is not an “upgrade” to GeoFence, but a fork of it, that users
>can migrate to.
>- GING is not endorsed by GeoSolutions, but has, at the beginning,
>Gabriel Roldan as the sole maintainer.
>- GING starts as a new community module and works its way up to
>extension status like any other module (including Geofence
><https://github.com/geoserver/geoserver/wiki/GSIP-164>) did.
>
> There is a number of advantages going this way:
>
>- Gabriel does not lose the large work investment in his fork, and
>gets a module that he’ll “be in charge of project maintenance for these
>customers for the foreseeable future” and will get a “codebase that's
>closer to pleasure to work on than to a hassle”.
>- There is no longer reason to carry around baggage, Gabriel can drop
>the other REST APIs and just keep the newer one.
>- The H2 dependency is no longer a problem, it can be dropped right
>away.
>- Gabriel still gets documentation and UI that he can adapt to the
>“GING” name, without having to recreate all of that from scratch.
>- The developer community avoids a fight, and the user community gets
>two alternative securit

Re: [Geoserver-devel] PRs to Update Spring and Spring Security

[Gabriel Roldan]

On Wed, 18 Jan 2023 at 07:31, Andrea Aime 
wrote:

> Hi Joseph,
> thanks for sharing the progress. Some additions inline below
>
> On Tue, Jan 17, 2023 at 10:31 PM Joseph Miller 
> wrote:
>
>> *Spring MVC Content Negotiation*
>> ContentNegotiationConfigurer.favorPathExtension is deprecated (and no
>> longer the default configuration) because Spring wants to discourage
>> extensions in paths. Removing extensions would cause GeoServer REST API
>> backwards compatibility issues that will have to be addressed in the
>> future. For now, we are suppressing the deprecation warning and turning on
>> this configuration option.
>>
>
> Some references about content negotiation and the deprecation itself, for
> reference:
>
>- Docs about suffix match
>
> 
>- The issue that deprecated path extensions
>
>
> This issue affects the REST API, which uses a suffix match to decide about
> the response content.  The OGC API module is currently not using such a
> convention, so it's not affected.
>

Note we've already faced that problem in GeoServer Cloud, and fixed it with
this:

https://github.com/geoserver/geoserver-cloud/commit/c9105e2d265ca89601157fcb58cd73ad2b750c82#diff-ce2a76336b064b1b6698bdbcacdde96f6635f31ed2ba982efb46ae4ba3f638f9R51

Basically:
ContentNegotiationConfigurer.favorPathExtension(true)
and
handlerMapping.setUseSuffixPatternMatch(true);
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] GeoServer 2.23-RC1 released

[Gabriel Roldan]

The GeoServer team is pleased to share the release of GeoServer 2.23-RC1
<https://geoserver.org/release/2.23-RC1/>.

Check out the announcement
<https://geoserver.org/announcements/2023/03/14/geoserver-2-23-RC1-released.html>
for
a summary and pictures of the hard work that leads to this:

   - Java 11 Minimum
   - CSS Cleanup
   - Spring Upgrade
   - Windows installer Java 11 Update
   - Feature Type Description
   - OGC CITE Fixes
   - And a whole host of fixes and improvements
   <https://github.com/geoserver/geoserver/releases/tag/2.23-RC1>

Thanks to everyone who helped make this release and tested all the upgrades
and fixes as they developed - due to your effort this release candidate is
*much* better.

Please *reply to this email with the results of your testing *- we are
especially interested in the following:

   - The *new functionality and documentation*? Does it work
   with your data? Do the docs make sense? Ask questions...
   - This is the first release that requires Java 11 as a minimum, but let
   us know *what JDK you are using* and how the upgrade to Java 11 goes
   - We really want to know about *any regressions* - do not think for a
   moment that any issue is evident and we will notice (we won't it is up to
   you to speak up)
   - A small thing: the downloads and extensions now include *HTML
pages* (rather
   than text files) for readme, running instructions, and licenses. If you
   spot anything missing or incorrect please let us know.

We do our best to acknowledge everyone who responds during this testing
window as part of the final release announcement. This is your chance to
take part; give the release candidate a download, let us know how it works,
and we can get GeoServer 2.23.0 out next.
--
Gabriel Roldan
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP-216 GeoFence 4.0.x

[Gabriel Roldan]

hink this is a
> key upgrade that is blocking work :(
>

The challenge is the H2 database upgrade. I think that'd be why
Emmanuele's  branch is three years old.


> 3) REST API differences between standalone and embedded --> definition of
> a new OpenAPI 3.0 interface
>
> What is impacted by this? Is it just the integration between geoserver and
> geofence or is there more functionality (such as GeoNode or MapStore) that
> requires care?
>

My understanding from the PMC meeting the other day, I might be wrong, is
anyone is hardly using the standalone version of the REST API, so much that
Andrea mentioned they thought of ditching it and just keep the one provided
by GeoServer.


> reading: I see you acknowledge the REST API change. Is it possible to run
> both a v1 and a v2 rest api concurrently? We will need to hear from the
> community what the impact of this change is. It is always hard when your
> work impacts others as you need to ensure they have budget to proceed with
> the change.
>

Yes, that's the proposal, to let the GeoServer plugin run both v1 and v2.
In any case, it'd use v2 to communicate with a remote GeoFence
when using the remote plugin (to replace Spring RMI), but whether to expose
the v2 can be a configuration choice. Meanwhile,
anyone can use the OpenAPI specification to code-generate clients and
upgrade to v2 at their own pace.


>
> 4) Use of spring RMI -->
>
> Repository adapters? Not sure I follow the approach.
>

As explained above. The idea is to get rid of Spring RMI as it's
deprecated, and use the REST API to fetch data from Geofence, while eating
our own dogfood.

Cheers,
Gabe

>
> --
> Jody Garnett
>
>
> On Tue, Mar 7, 2023 at 6:34 PM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi list,
>>
>> I've just created a GSIP (216) with a proposal to make several
>> improvements to GeoFence.
>>
>> Please see https://github.com/geoserver/geoserver/wiki/GSIP-216 for
>> details.
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Developer
>>
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] GSIP-216 GeoFence 4.0.x

[Gabriel Roldan]

n by the developers’ community (and in particular module
>maintainers) in advance, to explore the possible alternative design, and
>find one that both parties agree upon. It would need more time to be
>investigated, tested, discussed, and in the end adopted and would give time
>to the other devs to get accustomed to it.
>
>  That would be this one. Given I'm committed to it I'd rather get the go
ahead to have a 4.x branch or be forced to work on it from my fork alone.

Thanks again for the review and comments, looking forward to yours and
anyone else's.

Cheers,
Gabe.


> Looking forward in reading your feedback.
>
>Cheers,
>Emanuele
>
>
> [1] https://github.com/geoserver/geofence/issues/128
> [2] https://github.com/geoserver/geofence/wiki/GeoFence-REST-API
>
> On Wed, Mar 8, 2023 at 3:35 AM Gabriel Roldan <
> gabriel.rol...@camptocamp.com> wrote:
>
>> Hi list,
>>
>> I've just created a GSIP (216) with a proposal to make several
>> improvements to GeoFence.
>>
>> Please see https://github.com/geoserver/geoserver/wiki/GSIP-216 for
>> details.
>>
>>
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

[Geoserver-devel] 2.23-RC1 - release artefacts available for testing now

[Gabriel Roldan]

Hi all,
The release artifacts for 2.23-RC1 are ready, please grab them and give
them a shot
https://build.geoserver.org/view/release/job/geoserver-release/110/artifact/distribution/2.23-RC1/
and test especially if you are on windows or a Mac.

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

Re: [Geoserver-devel] 2.23-RC /1.23-RC/29-RC Release train is starting

[Gabriel Roldan]

Hi all,

just a heads up that GeoServer's main branch version was updated to
2.24-SNAPSHOT,
depending on GeoTools 30-SNAPSHOT, and GeoWebCache 1.24-SNAPSHOT.

Cheers,

On Wed, 8 Mar 2023 at 11:08, Gabriel Roldan 
wrote:

> Heads up, I'm going to kick off the 29-RC release of GeoTools this
> morning, depending on how this goes Andrea will do GWC 1.23-RC and then I
> will continue with GeoServer 2.23-RC.
>
> Cheers,
> --
> Gabriel Roldán
>


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

[Geoserver-devel] 2.23-RC /1.23-RC/29-RC Release train is starting

[Gabriel Roldan]

Heads up, I'm going to kick off the 29-RC release of GeoTools this morning,
depending on how this goes Andrea will do GWC 1.23-RC and then I will
continue with GeoServer 2.23-RC.

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

[Geoserver-devel] GSIP-216 GeoFence 4.0.x

[Gabriel Roldan]

Hi list,

I've just created a GSIP (216) with a proposal to make several improvements
to GeoFence.

Please see https://github.com/geoserver/geoserver/wiki/GSIP-216 for details.

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

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

[Geoserver-devel] 2.23-RC Release train

[Gabriel Roldan]

Hi,
Due to a lack of capacity, I couldn't yet start with the 2.23-RC release,
so sorry for the delay.
That said, as the release manager I'm announcing the start of the release
train by tomorrow Wednesday, March 8.

Cheers,

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

Re: [Geoserver-devel] seeking permission to increase release data directory size

[Gabriel Roldan]

I've been secretly wishing we shipped with a nicer default datadir for
years, something like ne indeed.
Maybe we can evaluate decoupling the data/ directory (data/release,
data/minimal, etc.) from the
codebase into its own repository and make the data/ directory a submodule
instead?

In that directory we could even enable git LFS support and include somewhat
bigger data files.

2c.
Gabe

On Tue, 24 Jan 2023 at 11:01, Andrea Aime 
wrote:

> (whoops, noticed that I answered only privately, sending to ml as well):
>
> Geoserver is already at a stupid 110MB size... 3.5MB more is like a 3%
> increase, not much
>

> At the same time, this is exactly how it grows... Little by little over
> the years.
> So, I'd cast a "zero" vote on this.
>
> I was looking recently on how to put GS on a diet and one big contributor
> to size is the SQLite JDBC driver, which packs native libs for a large
> variety of platforms. If it was doctored to remove support for the less
> common ones, it would shrink by a few MB for sure. Just thinking out loud.
>
> Cheers
> Andrea
>
> On Tue, Jan 24, 2023 at 7:54 AM Jody Garnett 
> wrote:
>
>> While twitter was still a thing I received some feedback online with
>> respect to data directory for GeoServer 2.22.x series.
>>
>> I have a PR here https://github.com/geoserver/geoserver/pull/6527 adding
>> disputed regions to our map, and having some ability to demo LANGAGUE=
>> parameter for GetMap.
>>
>> While I would like to continue, and set up a few alternative styles for
>> ne:world layergroup - I do not wish to put in any more effort unless we are
>> comfortable growing the data directory by 3.5 MB in order to jump to 1:50m
>> scale where disputed regions is available.
>>
>> So what do you think? Checkout
>> https://github.com/geoserver/geoserver/pull/6527 which has some screen
>> shots.
>> --
>> Jody Garnett
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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

Re: [Geoserver-devel] GeoFence Rule limits not working?

[Gabriel Roldan]

Hi Emanuele,

Thanks for your reply. After I better learned how geofence rules work, I
managed to get a working
solution for my use case, though I had to adapt my intermediate logic.

I'm translating access rules from an external system.
This system defines so-called "plan areas" for different companies.
Each company can have assigned several such plan areas, each with its
geometry filter.
Users logged in get a company role from an external authentication provider.
Then geofence is configured to use roles for authorization (with an *
wildcard).

What I was trying to do, was to have geofence limit rules matching 1:1 plan
area geometry filters.
So let's say company A can only see Paris and Berlin. For that, the
external system gives me
one plan area for each region with their respective allowed area geometry.

If I create two LIMIT rules, one for Paris and another for Berlin, followed
by an ALLOW rule,
geofence will intersect their geometries producing an empty polygon.

If I try to create two separate sets of LIMIT/ALLOW rules, it won't let me,
complaining with a duplicate key exception (i.e.
both rule sets would match the same filter for
service/request/workspace/layer).

So what I ended up doing is to merge the plan areas geometries before
creating the geofence rules, and
create one single rule with the geometry union of all the areas allowed for
each company.

Cheers,
Gabe
On Wed, 7 Dec 2022 at 08:56, Emanuele Tajariol <
emanuele.tajar...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
>
> limits work by, well, limiting :) so every matched LIMIT rule will add
> further limitations.
>
> Is that correct? or an edge case?
>
>
> It's not an edge case, it's this way by design and described in paragraph 
> Rule-matching
> / constraints-merging
> <https://github.com/geoserver/geofence/wiki/Rule-matching#constraints-merging>
> :
>
> The constraints merging is performed in the most restrictive way:
>>  -  resulting allowed area will be the intersection of all the allowed
>> areas;
>
>
> Area unions are indeed performed when considering groups: if a user is
> added to a group, its privileges will be widened to also allow permissions
> granted by belonging to the new group.
>
> Just out of curiosity, what is your use case requiring enlarging limit
> accesses?
>
>Cheers,
>Emanuele
>
>
>
> On Mon, Dec 5, 2022 at 7:23 PM Gabriel Roldan 
> wrote:
>
>> Hi Andrea,
>>
>> thanks for your reply, evidently I've misinterpreted the documentation
>> and didn't realize a limit rule had to be followed by an allow rule.
>>
>> My problem is now that I still can't have multiple limit rules, because
>> the merged AccessInfoInternal (as per resolveRuleset()),
>> will have its allowed geometry set to the intersection of all the
>> limit-rule geometries, instead of their union.
>> Is that correct? or an edge case?
>>
>> Cheers,
>> Gabe
>>
>>
>> On Sat, 3 Dec 2022 at 16:42, Andrea Aime <
>> andrea.a...@geosolutionsgroup.com> wrote:
>>
>>> Yep, the documentation about rule matching seems to confirm what I said:
>>>
>>> https://github.com/geoserver/geofence/wiki/Rule-matching#rule-evaluation
>>>
>>> Cheers
>>> Andrea
>>>
>>> On Fri, Dec 2, 2022 at 5:30 PM Andrea Aime <
>>> andrea.a...@geosolutionsgroup.com> wrote:
>>>
>>>> Hi Gabriel,
>>>> if memory serves me well (and I might be wrong) limit rules only apply
>>>> on top of a rule
>>>> allowing access, so you need two rules, one that says "yes you can
>>>> access" and another
>>>> of limit type saying "but with the following limitations"
>>>>
>>>> Cheers
>>>> Andrea
>>>>
>>>> On Fri, Dec 2, 2022 at 1:23 PM Gabriel Roldan 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> I think this is a GeoFence bug, but would need confirmation.
>>>>>
>>>>> RuleLimits are not being respected, as far as I can see.
>>>>> For example, if I want to create a Rule stating a given user or role
>>>>> can see all layers but within a given area, my understanding is
>>>>> a Rule with Access Type = LIMIT, and an allowed area WKT would do,
>>>>> but that's just not being applied.
>>>>>
>>>>> Digging into it, it looks like RuleReaderServiceImpl's 
>>>>> resolveRuleset(List
>>>>> ruleList)
>>>>> <https://github.com/geoserver/geofence/blob/cdaee4ac2cc7a3f6dc692a2dec282f6667a40

Re: [Geoserver-devel] GeoFence Rule limits not working?

[Gabriel Roldan]

Hi Andrea,

thanks for your reply, evidently I've misinterpreted the documentation and
didn't realize a limit rule had to be followed by an allow rule.

My problem is now that I still can't have multiple limit rules, because the
merged AccessInfoInternal (as per resolveRuleset()),
will have its allowed geometry set to the intersection of all the
limit-rule geometries, instead of their union.
Is that correct? or an edge case?

Cheers,
Gabe


On Sat, 3 Dec 2022 at 16:42, Andrea Aime 
wrote:

> Yep, the documentation about rule matching seems to confirm what I said:
>
> https://github.com/geoserver/geofence/wiki/Rule-matching#rule-evaluation
>
> Cheers
> Andrea
>
> On Fri, Dec 2, 2022 at 5:30 PM Andrea Aime <
> andrea.a...@geosolutionsgroup.com> wrote:
>
>> Hi Gabriel,
>> if memory serves me well (and I might be wrong) limit rules only apply on
>> top of a rule
>> allowing access, so you need two rules, one that says "yes you can
>> access" and another
>> of limit type saying "but with the following limitations"
>>
>> Cheers
>> Andrea
>>
>> On Fri, Dec 2, 2022 at 1:23 PM Gabriel Roldan 
>> wrote:
>>
>>> Hi,
>>> I think this is a GeoFence bug, but would need confirmation.
>>>
>>> RuleLimits are not being respected, as far as I can see.
>>> For example, if I want to create a Rule stating a given user or role
>>> can see all layers but within a given area, my understanding is
>>> a Rule with Access Type = LIMIT, and an allowed area WKT would do,
>>> but that's just not being applied.
>>>
>>> Digging into it, it looks like RuleReaderServiceImpl's 
>>> resolveRuleset(List
>>> ruleList)
>>> <https://github.com/geoserver/geofence/blob/cdaee4ac2cc7a3f6dc692a2dec282f6667a4031e/src/services/core/services-impl/src/main/java/org/geoserver/geofence/services/RuleReaderServiceImpl.java#L303-L343>
>>> does nothing when a Rule has RuleLimits, boiling down to
>>>
>>> private AccessInfoInternal resolveRuleset(List ruleList) {
>>> List limits = new ArrayList<>();
>>> AccessInfoInternal ret = null;
>>> for (Rule rule : ruleList) {
>>> if(ret != null)
>>> break;
>>> switch(rule.getAccess()) {
>>> case LIMIT:
>>>RuleLimits rl = rule.getRuleLimits();
>>>if(rl != null)
>>>limits.add(rl);
>>> break;
>>>  
>>> }
>>> }
>>> return ret;
>>> }
>>>
>>> That is, adds the RuleLimits to the limits list, and then just returns
>>> null.
>>>
>>> Additionally, the following makes it build an AccessInfoInternal only
>>> for the first Rule in the ruleList:
>>> for (Rule rule : ruleList) {
>>> if(ret != null)
>>> break;
>>>
>>> Meaning that if more than one rule matched the filter, only the first
>>> one will be considered.
>>>
>>> My use case is an external system sets up rules for companies based on
>>> roles, which come from another system, and
>>> can have several rules per company with different allowed areas, for all
>>> layers. Ideally, I shouldn't need to merge these
>>> areas in order to create a single rule, but have them match the external
>>> system's.
>>>
>>> I've a patch [1] that makes both consider the RuleLimits and all the
>>> matching rules
>>> in resolveRuleset(List ruleList) argument.
>>>
>>> [1]
>>> https://github.com/groldan/geofence/commit/5290c1760746f4e93ff4915c9e80a19a09e433be
>>>
>>> With it, I can set up two Rules with different allowed areas, both for
>>> all layers, and have them applied as expected (or as I understand it's
>>> expected). The following image is a layer preview of tiger_roads with both
>>> rules applied:
>>>
>>> [image: image.png]
>>>
>>> So, is my understanding correct and can I proceed to issue a PR?
>>>
>>> Cheers,
>>>
>>> --
>>> Gabriel Roldán
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>>
>> --
>>
>> Regards,
>>
>> Andrea Aime
&g

Re: [Geoserver-devel] GeoFence dev branch

[Gabriel Roldan]

Hi Emanuele,

thanks a lot, my bad for not noticing.

Cheers,
Gabe

On Mon, 5 Dec 2022 at 09:56, Emanuele Tajariol <
emanuele.tajar...@geosolutionsgroup.com> wrote:

> Hi Gabriel,
>
> Please disregard the master branch, since it has been dismissed in favor
> of main (when you browse to https://github.com/geoserver/geofence, github
> shows it as default).
> Master evolved (with breaking changes for the standalone version) from
> the 3.4, but it was never used (there are no tags on it). Its "3.5" version
> in pom file was the next in line version from 3.4, but it was never
> released.
> The "real" (released) 3.5 tags are on main, not master.
>
> About creating new branches: we usually change version number and create a
> new branch for the previous one when there are somewhat breaking changes
> (e.g. DTO or major dependency changes).
> When there are only fixes we prefer working on the existing branch.
>
> Anway, this mail is just for clarification, since I guess the spotted
> issue is not a bug at all :)
>
> I also reported these info about branches at
> https://github.com/geoserver/geofence/wiki/GS-GF-Compatibility-matrix#a-note-about-main-and-master-branches
>
>Cheers,
>Emanuele
>
>
>
> On Fri, Dec 2, 2022 at 12:58 PM Gabriel Roldan 
> wrote:
>
>> Hi,
>> I'm working on a GeoFence issue for which I'll write a separate email.
>> This one is about collaboration. I see the master branch is at
>> 3.5-SNAPSHOT
>> but 3.6.0 is released, and though there's a 3.5.x branch, there's no
>> 3.6.x.
>>
>> So the question is if master should be at 3.6-SNAPSHOT, or a 3.6.x branch
>> should be created.
>>
>> In any case, can the appropriate branch be created/updated?
>>
>> TIA
>> --
>> Gabriel Roldán
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
> Regards,
> Emanuele Tajariol
> ==
> GeoServer Professional Services from the experts!
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Emanuele Tajariol
> Technical Lead
>
> GeoSolutions Group
> mobile: +39 347 7895230
> office: +39 0584 962313
> fax:  +39 0584 1660272
>
> https://www.geosolutionsgroup.com/
> http://twitter.com/geosolutions_it
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail.
>
>

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

[Geoserver-devel] GeoFence Rule limits not working?

[Gabriel Roldan]

Hi,
I think this is a GeoFence bug, but would need confirmation.

RuleLimits are not being respected, as far as I can see.
For example, if I want to create a Rule stating a given user or role
can see all layers but within a given area, my understanding is
a Rule with Access Type = LIMIT, and an allowed area WKT would do,
but that's just not being applied.

Digging into it, it looks like RuleReaderServiceImpl's
resolveRuleset(List
ruleList)

does nothing when a Rule has RuleLimits, boiling down to

private AccessInfoInternal resolveRuleset(List ruleList) {
List limits = new ArrayList<>();
AccessInfoInternal ret = null;
for (Rule rule : ruleList) {
if(ret != null)
break;
switch(rule.getAccess()) {
case LIMIT:
   RuleLimits rl = rule.getRuleLimits();
   if(rl != null)
   limits.add(rl);
break;
 
}
}
return ret;
}

That is, adds the RuleLimits to the limits list, and then just returns null.

Additionally, the following makes it build an AccessInfoInternal only for
the first Rule in the ruleList:
for (Rule rule : ruleList) {
if(ret != null)
break;

Meaning that if more than one rule matched the filter, only the first one
will be considered.

My use case is an external system sets up rules for companies based on
roles, which come from another system, and
can have several rules per company with different allowed areas, for all
layers. Ideally, I shouldn't need to merge these
areas in order to create a single rule, but have them match the external
system's.

I've a patch [1] that makes both consider the RuleLimits and all the
matching rules
in resolveRuleset(List ruleList) argument.

[1]
https://github.com/groldan/geofence/commit/5290c1760746f4e93ff4915c9e80a19a09e433be

With it, I can set up two Rules with different allowed areas, both for all
layers, and have them applied as expected (or as I understand it's
expected). The following image is a layer preview of tiger_roads with both
rules applied:

[image: image.png]

So, is my understanding correct and can I proceed to issue a PR?

Cheers,

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

[Geoserver-devel] GeoFence dev branch

[Gabriel Roldan]

Hi,
I'm working on a GeoFence issue for which I'll write a separate email.
This one is about collaboration. I see the master branch is at 3.5-SNAPSHOT
but 3.6.0 is released, and though there's a 3.5.x branch, there's no 3.6.x.

So the question is if master should be at 3.6-SNAPSHOT, or a 3.6.x branch
should be created.

In any case, can the appropriate branch be created/updated?

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

Re: [Geoserver-devel] Workpace/layer home page selection problematic with large data directories

[Gabriel Roldan]

Hi Andrea,

for the record, here's the branch with the catalog loader optimization [1].
I need to add some docs before
proposing it as a community module, but it's working ok in a vanilla
geoserver deployment with ~80k layers, ~4k workspaces,
and wms/wfs/wcs/wmts services configured for each workspace individually,
which surprisingly was a big perf offender.

That said, it won't help with the home page combos at all.

My proposal would be to use progressive loading instead of preemptive
loading of all workspaces/layers. The downside is you need to
know at least a couple of letters about what you're looking for, but IMO
it's a good compromise. Catalog-side wise, it'd only perform
well if there's an actual full-text-search engine backing the search. Back
in the day I had a prototype for an in-memory lucene index
running the searches for the UI's full text searches that worked like a
charm, but IIRC missed a good update of the index whenever
something changes. That could be something to do some research on.

[1]
https://github.com/groldan/geoserver/tree/catalog/perf/data_directory_loader


On Thu, 24 Nov 2022 at 07:18, Andrea Aime 
wrote:

> Hi all,
> I've just got a report from a customer that they tried to upgrade to
> 2.22.0, but had to quickly revert back to 2.21.x, as the GeoServer home
> page was unreachable.
>
> What is interesting about that deployment is the number of layer, well
> above 20k. Not the largest I've seen, but large. Also, all the layers are
> sourced from an Oracle database.
> In their case, the home page takes several minutes to load.
>
> Locally I have an oddball test data directory with 40k layers, but with an
> easing factor, it's a "many times copy" of the GeoServer demo layers,
> meaning it's all shapefiles.
> The landing page for me displays quick enough (few seconds), but then
> the browser is on its knees, completely unresponsive, for 10+ seconds.
> After that, trying to use the workspace/layer dropdown also incurs in
> severe slowdown, with the browser blocked for several seconds.
> Chrome reports that one tab with the home page is using 776MB of memory,
> too.
>
> Considering I've seen installations with up to 1 million layers (a case
> where they actually had 3 millions, and split them across 3 different data
> directories), this is a serious problem...
>
> I have also seen Gabriel experiment with large geoserver-cloud deployments
> with a lot of workspaces (tens of thousands? more?) but I cannot find the
> relevant branch anymore (believe it was about better parallelizing data
> directory loading, cannot find the commit anymore).
>
> How to address it though? Throwing in a couple of ideas:
>
>- Make the functionality opt-in or opt-out via a flag or UI
>configuration. The flag might be hard to discover, but the UI setting could
>be hard to reach if one cannot get to the home page to start with...
>- Automatically disable the dropdowns after a certain threshold of
>workspaces layers is reached, with the threshold being configurable? Say
>1000 for example? However it might still cause issues for data sources that
>are slow to be connected (I'm guessing part of the slowness is due to some
>data type verification that requires actual connection to the data source,
>based on the fact the Oracle seems a lot slower to just generate the page
>
> Any other idea?
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> 

[Geoserver-devel] [JIRA] (GEOS-10760) GeoFence XML REST API broken: wrong element names

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiZTYyMzk2ZWM3YmUxNDZhNDlmMzI4ZjMyMGFmNWEzYmUiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10760?atlOrigin=eyJpIjoiZTYyMzk2ZWM3YmUxNDZhNDlmMzI4ZjMyMGFmNWEzYmUiLCJwIjoiaiJ9
 ) GEOS-10760 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10760?atlOrigin=eyJpIjoiZTYyMzk2ZWM3YmUxNDZhNDlmMzI4ZjMyMGFmNWEzYmUiLCJwIjoiaiJ9
 ) GeoFence XML REST API broken: wrong element names ( 
https://osgeo-org.atlassian.net/browse/GEOS-10760?atlOrigin=eyJpIjoiZTYyMzk2ZWM3YmUxNDZhNDlmMzI4ZjMyMGFmNWEzYmUiLCJwIjoiaiJ9
 )

Issue Type: Bug Affects Versions: 2.22.0 Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Components: GeoFence Created: 28/Nov/22 3:45 PM Priority: Medium Reporter: 
Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

GeoFence-server REST API outputs wrong element names.

Expected (as in 2.21.0):

curl -u admin:geoserver "http://localhost:8080/geoserver/rest/geofence/rules; 
-H "Accept: application/xml"|xmllint --format -


 
   DENY
   100
   ORG_205738
   topp
 


Actual (as in 2.22.0):

curl -u admin:geoserver "http://localhost:8080/geoserver/rest/geofence/rules; 
-H "Accept: application/xml"|xmllint --format -


 1
 
   
 1
 100
 
 ORG_205738
 
 topp
 
 
 
 DENY
 
 
   
 


( 
https://osgeo-org.atlassian.net/browse/GEOS-10760#add-comment?atlOrigin=eyJpIjoiZTYyMzk2ZWM3YmUxNDZhNDlmMzI4ZjMyMGFmNWEzYmUiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10760#add-comment?atlOrigin=eyJpIjoiZTYyMzk2ZWM3YmUxNDZhNDlmMzI4ZjMyMGFmNWEzYmUiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100210- 
sha1:4037f92 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10717) XStreamServiceLoader performance improvement with XstreamPersister caching

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNWI3OGExZGY1ZGI1NDk3Yjg4ZWNlMTI2YTRhZTk1MzUiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10717?atlOrigin=eyJpIjoiNWI3OGExZGY1ZGI1NDk3Yjg4ZWNlMTI2YTRhZTk1MzUiLCJwIjoiaiJ9
 ) GEOS-10717 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10717?atlOrigin=eyJpIjoiNWI3OGExZGY1ZGI1NDk3Yjg4ZWNlMTI2YTRhZTk1MzUiLCJwIjoiaiJ9
 ) XStreamServiceLoader performance improvement with XstreamPersister caching ( 
https://osgeo-org.atlassian.net/browse/GEOS-10717?atlOrigin=eyJpIjoiNWI3OGExZGY1ZGI1NDk3Yjg4ZWNlMTI2YTRhZTk1MzUiLCJwIjoiaiJ9
 )

Issue Type: Improvement Affects Versions: 2.21.1 Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 21/Oct/22 4:30 AM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

XStreamServiceLoader creates and initializes a new XStreamPersister every time 
it has to save or load a ServiceInfo, which comes with considerable overhead 
when depersisting thousands of service files.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10717#add-comment?atlOrigin=eyJpIjoiNWI3OGExZGY1ZGI1NDk3Yjg4ZWNlMTI2YTRhZTk1MzUiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10717#add-comment?atlOrigin=eyJpIjoiNWI3OGExZGY1ZGI1NDk3Yjg4ZWNlMTI2YTRhZTk1MzUiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100209- 
sha1:392b984 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10714) DefaultGeoServerFacade throws ConcurrentModificationException for workspace settings and services

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiYjA1ZDk0NzVlYTQzNDkxNmI5ZDgzMjQ5MzY0MDVlNDQiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10714?atlOrigin=eyJpIjoiYjA1ZDk0NzVlYTQzNDkxNmI5ZDgzMjQ5MzY0MDVlNDQiLCJwIjoiaiJ9
 ) GEOS-10714 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10714?atlOrigin=eyJpIjoiYjA1ZDk0NzVlYTQzNDkxNmI5ZDgzMjQ5MzY0MDVlNDQiLCJwIjoiaiJ9
 ) DefaultGeoServerFacade throws ConcurrentModificationException for workspace 
settings and services ( 
https://osgeo-org.atlassian.net/browse/GEOS-10714?atlOrigin=eyJpIjoiYjA1ZDk0NzVlYTQzNDkxNmI5ZDgzMjQ5MzY0MDVlNDQiLCJwIjoiaiJ9
 )

Issue Type: Bug Affects Versions: 2.21.1 Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 20/Oct/22 5:11 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

DefaultGeoServerFacade, backing GeoServerImpl, throws 
ConcurrentModificationException if accessed by multiple threads to 
add/save/query SettingsInfo’s and ServiceInfos.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10714#add-comment?atlOrigin=eyJpIjoiYjA1ZDk0NzVlYTQzNDkxNmI5ZDgzMjQ5MzY0MDVlNDQiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10714#add-comment?atlOrigin=eyJpIjoiYjA1ZDk0NzVlYTQzNDkxNmI5ZDgzMjQ5MzY0MDVlNDQiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100209- 
sha1:392b984 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10676) Support uploading .bmp and .gif images as SLD Package icons through restconfig

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiZGNjZmEzZDhhZmVhNDkxZWE2ZDBhM2FiNzY2NWUyNDIiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10676?atlOrigin=eyJpIjoiZGNjZmEzZDhhZmVhNDkxZWE2ZDBhM2FiNzY2NWUyNDIiLCJwIjoiaiJ9
 ) GEOS-10676 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10676?atlOrigin=eyJpIjoiZGNjZmEzZDhhZmVhNDkxZWE2ZDBhM2FiNzY2NWUyNDIiLCJwIjoiaiJ9
 ) Support uploading .bmp and .gif images as SLD Package icons through 
restconfig ( 
https://osgeo-org.atlassian.net/browse/GEOS-10676?atlOrigin=eyJpIjoiZGNjZmEzZDhhZmVhNDkxZWE2ZDBhM2FiNzY2NWUyNDIiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Components: REST Created: 28/Sep/22 3:22 PM Priority: Medium Reporter: 
Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

Given a .zip file with an sld.sld file and a symbolizer with an external 
graphic provided in the .zip file, of type .bmp or .gif, allow to create the 
style through the rest config API, and ensure the attached image resources are 
copied to the appropriate styles resource in the data directory.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10676#add-comment?atlOrigin=eyJpIjoiZGNjZmEzZDhhZmVhNDkxZWE2ZDBhM2FiNzY2NWUyNDIiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10676#add-comment?atlOrigin=eyJpIjoiZGNjZmEzZDhhZmVhNDkxZWE2ZDBhM2FiNzY2NWUyNDIiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100207- 
sha1:ee9e30a )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] PGRaster community module resurrection

[Gabriel Roldan]

Hi,

thanks for your replies.

So yes, for the time being, my intention was to trim down the geotools code
to the bare minimum
needed to support only pgraster, without the other gt-imagemosaic-jdbc
"spatial extensions", and include
it all as part of geoserver's pgraster community module to have the less
moving parts possible.

I guess the only question is whether that's acceptable from the licencing
point of view, since the copied
and refactored gt code is LGPL. I didn't change the licence for that code
of course. So, can it be kept
in geoserver at least while a community module? or should I create a new
pgraster unsupported extension
in geotools?

Cheers,
Gabe


On Tue, 6 Sept 2022 at 11:09, Jody Garnett  wrote:

> +1 please work with your customer to seek extension status.
>
> Personally I would prefer to see this restored to geotools long term, but
> that can be if it becomes stable enough for an extension.
>
> Jody
>
> On Mon, Sep 5, 2022 at 9:43 AM Gabriel Roldan 
> wrote:
>
>> Hi there,
>>
>> I've just created a PR to resurrect the pgraster community module:
>> https://github.com/geoserver/geoserver/pull/6166
>>
>> Since this is a customer requirement, consequently I'm stepping up
>> as maintainer.
>>
>> To do so, I've copied the required code from gt-imagemosaic-jdbc:2.26.x,
>> before the module was deleted from geotools, into pgraster itself, and
>> removed
>> support for other jdbc raster spatial extensions.
>>
>> Please let me know if that seems ok to the PSC.
>>
>> Cheers,
>> --
>> Gabriel Roldán
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
> --
> --
> Jody Garnett
>


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

[Geoserver-devel] PGRaster community module resurrection

[Gabriel Roldan]

Hi there,

I've just created a PR to resurrect the pgraster community module:
https://github.com/geoserver/geoserver/pull/6166

Since this is a customer requirement, consequently I'm stepping up
as maintainer.

To do so, I've copied the required code from gt-imagemosaic-jdbc:2.26.x,
before the module was deleted from geotools, into pgraster itself, and
removed
support for other jdbc raster spatial extensions.

Please let me know if that seems ok to the PSC.

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

[Geoserver-devel] embedded Geofence REST API not using JAXB element names

[Gabriel Roldan]

Hi there,

this is on main with geofence-server.

I wonder what is the actually expected encoding for Geofence Jaxb objects.
For example, the output of /geoserver/rest/geofence/rules will give
something like the xml fragment below, which doesn't match the annotations
in JaxbRuleList etc such as:

@XmlRootElement(name = "Rules") public class JaxbRuleList ...
@XmlRootElement(name = "Rule") public class JaxbRule...


2


2
0

ROLE_EDITOR





ALLOW




As far as I can see the controller is tested directly but can't find a test
that checks on the output encoding.

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

Re: [Geoserver-devel] KML endpoints

[Gabriel Roldan]

Hi, thanks.
It's useful insight to me cause I didn't realize it works just like the
/ows endpoint.
Whether it's useful as a feature I can't say. I guess we'll leave it be for
the time being.

Cheers!

On Thu, 4 Aug 2022 at 14:33, Andrea Aime 
wrote:

> Hi Gabriel,
> I can't give you an answer, but I share your doubts indeed the
> reflector is handled at /wms/kml, all those mappings seem to enable
> is to make a OGC service request on a "kml" endpoint, provided
> service="xyz" is included in the request, e.g:
>
>
> https://gs-main.geosolutionsgroup.com/geoserver/cite/kml?service=WMS=1.1.0=GetMap=cite%3Atopo4=330890.1192644071%2C6611319.913595974%2C669109.8807355929%2C9330120.055635015=330=768=EPSG%3A25835==application/openlayers
>
> but also:
>
>
> https://gs-main.geosolutionsgroup.com/geoserver/tiger/kml?service=WFS=1.0.0=GetFeature=tiger%3Atiger_roads=50
>
> Is this useful? It doesn't seem to be, at least to me.
>
> Cheers
> Andrea
>
>
> On Wed, Aug 3, 2022 at 2:46 AM Gabriel Roldan 
> wrote:
>
>> Hi there,
>>
>> looking at the KML endpoints mapping, the
>> "kmlURLMapping" SimpleUrlHandlerMapping
>> has entries for /kml and /kml/*
>>
>> I couldn't find any working example/doc for that uri. It seems all kml
>> requests
>> are to be handled by the kml reflector instead at /wms/kml and
>> /{workspace}/wms/kml,
>> except for /kml/icon/**
>>
>> Should the url mapping for /kml and /kml/* be removed or am I missing
>> something?
>>
>> Here's the definition of kmlURLMapping:
>>  
>>  
>>  
>>  
>>  
>>  kmlIconService
>>  dispatcher
>>  dispatcher
>>  
>>  
>>  
>>
>>
>> TIA,
>> --
>> Gabriel Roldán
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> GeoServer Professional Services from the experts!
>
> Visit http://bit.ly/gs-services-us for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions Group
> phone: +39 0584 962313
>
> fax: +39 0584 1660272
>
> mob:   +39  339 8844549
>
> https://www.geosolutionsgroup.com/
>
> http://twitter.com/geosolutions_it
>
> ---
>
> Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
> precisa che ogni circostanza inerente alla presente email (il suo
> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>
> This email is intended only for the person or entity to which it is
> addressed and may contain information that is privileged, confidential or
> otherwise protected from disclosure. We remind that - as provided by
> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
> e-mail or the information herein by anyone other than the intended
> recipient is prohibited. If you have received this email by mistake, please
> notify us immediately by telephone or e-mail
>


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

[Geoserver-devel] KML endpoints

[Gabriel Roldan]

Hi there,

looking at the KML endpoints mapping, the
"kmlURLMapping" SimpleUrlHandlerMapping
has entries for /kml and /kml/*

I couldn't find any working example/doc for that uri. It seems all kml
requests
are to be handled by the kml reflector instead at /wms/kml and
/{workspace}/wms/kml,
except for /kml/icon/**

Should the url mapping for /kml and /kml/* be removed or am I missing
something?

Here's the definition of kmlURLMapping:
 
 
 
 
 
 kmlIconService
 dispatcher
 dispatcher
 
 
 


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

[Geoserver-devel] [JIRA] (GEOS-10561) CatalogImpl.save(StoreInfo) business rule to handle ResourceInfo.namespace

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNzY4YjhhYzQ4MzY2NGQ5YjhiYzY1YWQwOTYzMGVmYjkiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10561?atlOrigin=eyJpIjoiNzY4YjhhYzQ4MzY2NGQ5YjhiYzY1YWQwOTYzMGVmYjkiLCJwIjoiaiJ9
 ) GEOS-10561 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10561?atlOrigin=eyJpIjoiNzY4YjhhYzQ4MzY2NGQ5YjhiYzY1YWQwOTYzMGVmYjkiLCJwIjoiaiJ9
 ) CatalogImpl.save(StoreInfo) business rule to handle ResourceInfo.namespace ( 
https://osgeo-org.atlassian.net/browse/GEOS-10561?atlOrigin=eyJpIjoiNzY4YjhhYzQ4MzY2NGQ5YjhiYzY1YWQwOTYzMGVmYjkiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 26/Jun/22 11:11 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

CoverageStoreEditPage and DataStoreEditPage duplicate code
for a poor job trying to maintain the consistency between a
StoreInfo workspaces and its children ResourceInfo namespace
properties.

Going through, and saving all the StoreInfo 's resources disregarding
whether the store has been assigned a different workspace doesn't only
waste resources and slows down the update store operations in both
web and rest, but produce as many update events as resources in the
store, which are no-ops, but can trigger unnecessary side effects
from catalog listeners.

Keeping the resources namespace in sync with their store's workspace
is clearly a Catalog business rule instead.

Remove the duplicate eager resource update code from CoverageStore
and DataStore edit pages, and implement the consistency enforcement
as a Catalog.save(StoreInfo) business rule, avoiding going through
the list of child resources if not needed, and ensuring the operation
is rolled back with counter-actions if anything fails.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10561#add-comment?atlOrigin=eyJpIjoiNzY4YjhhYzQ4MzY2NGQ5YjhiYzY1YWQwOTYzMGVmYjkiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10561#add-comment?atlOrigin=eyJpIjoiNzY4YjhhYzQ4MzY2NGQ5YjhiYzY1YWQwOTYzMGVmYjkiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100201- 
sha1:00501c8 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Propose a new community module: freemarker template editor

[Gabriel Roldan]

Sounds great indeed.

Can't give you the go-ahead though.

On Fri, 24 Jun 2022 at 16:09, Jean Pommier 
wrote:

> Hi dev list,
>
> I would like to propose a new community module : a web UI page for the
> edition of the FreeMarker templates.
>
> [image: edition-page.png]
>
> This is an old project of mine, that hadn't gone through the community
> module step and got buried at some point.
>
> Some people from the geOrchestra community have expressed a keen interest
> in this module and had me resurrect it. This is why I would like to bring
> it back to life and have it as community module.
>
> It is a simple UI, almost simplistic. The editor is a plain TextArea. But
> it allows to easily manage the templates' inheritance system (from default
> to workspace to store to layer) and have an easy view of where the current
> template files are taken from. On the authentication level, it is available
> for whomever has the admin rights on a workspace (no need to belong to
> admin group).
>
> It is working fine on master. The code is on my repo
> ,
> ready to be pulled in. I have written a documentation
> 
> page too. I already have signed an individual contributor licence
> agreement with OSGeo.
>
> I hope you will like it,
>
> Best,
>
> Jean
> --
>
> *Jean Pommier -- pi-Geosolutions*
>
> Ingénieur, consultant indépendant
>
> Tél. : (+33) 6 09 23 21 36
> E-mail : j...@pi-geosolutions.fr
> Web : www.pi-geosolutions.fr
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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

[Geoserver-devel] [JIRA] (GEOS-10560) Make GeoServerConfigurationLock reentrant

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNWI2NzM0MjQwNjQ2NDEzNmE1MzRlMTBhMjBhM2JjNDQiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10560?atlOrigin=eyJpIjoiNWI2NzM0MjQwNjQ2NDEzNmE1MzRlMTBhMjBhM2JjNDQiLCJwIjoiaiJ9
 ) GEOS-10560 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10560?atlOrigin=eyJpIjoiNWI2NzM0MjQwNjQ2NDEzNmE1MzRlMTBhMjBhM2JjNDQiLCJwIjoiaiJ9
 ) Make GeoServerConfigurationLock reentrant ( 
https://osgeo-org.atlassian.net/browse/GEOS-10560?atlOrigin=eyJpIjoiNWI2NzM0MjQwNjQ2NDEzNmE1MzRlMTBhMjBhM2JjNDQiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 24/Jun/22 11:12 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

GeoServerConfigurationLock uses reentrant read/write locks internally but does 
not preserve that behavior.

Since the lock can't know about the call chain that results in a lock request, 
it's important that reentrancy is preserved.

A typical scenario is component A acquires a write lock to perform a bunch of 
operations through component B, which also acquires a write lock to perform 
more granular operations.

Component B unlocks, and then component A unlocks. Currently, the 
ThreadLocal is cleared on the first unlock, leaving open locks when 
the next call to GeoServerConfigurationLock.unlock() arrives.

Also, if a write lock is already held, and a read lock is requested down the 
stream, the write lock shall be preserved.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10560#add-comment?atlOrigin=eyJpIjoiNWI2NzM0MjQwNjQ2NDEzNmE1MzRlMTBhMjBhM2JjNDQiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10560#add-comment?atlOrigin=eyJpIjoiNWI2NzM0MjQwNjQ2NDEzNmE1MzRlMTBhMjBhM2JjNDQiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100201- 
sha1:00501c8 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10559) Lazy initialization of GetMapKvpRequestReader's HTTP client used to fetch remote styles

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMWY1OTNkZTc2OGY2NGM0MWI5NDIyMDBjMWNjZjExNjkiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10559?atlOrigin=eyJpIjoiMWY1OTNkZTc2OGY2NGM0MWI5NDIyMDBjMWNjZjExNjkiLCJwIjoiaiJ9
 ) GEOS-10559 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10559?atlOrigin=eyJpIjoiMWY1OTNkZTc2OGY2NGM0MWI5NDIyMDBjMWNjZjExNjkiLCJwIjoiaiJ9
 ) Lazy initialization of GetMapKvpRequestReader's HTTP client used to fetch 
remote styles ( 
https://osgeo-org.atlassian.net/browse/GEOS-10559?atlOrigin=eyJpIjoiMWY1OTNkZTc2OGY2NGM0MWI5NDIyMDBjMWNjZjExNjkiLCJwIjoiaiJ9
 )

Issue Type: Improvement Affects Versions: 2.21.0 Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Components: WMS Created: 23/Jun/22 8:33 PM Priority: Medium Reporter: 
Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

GetMapKvpRequestReader creates an apache CloseableHttpClient on its constructor.

To do so, it needs to get the stles cache configuration from the 
org.geoserver.wms.WMS facade.

Depending on the bootstrap conditions, this triggers eager initialization of 
beans, that can lead to a circular reference error. This issue is observed in 
GeoServer Cloud.

Also, the eager initialization of the HTTP client can result in a waste of 
resources, because it may never use it, and because there are subclasses that 
definitely won’t use it.

Some of these subclasses are not spring beans, but created on-demand, such as 
WMSRequests.LayerParser, which currently adds a CatalogListener on each 
invocation of WMSRequests.getGetMapParams(), that is never removed from the 
catalog, hence being a memory leak.

As a solution, the HTTP client used by GetMapKvpRequestReader shall be lazily 
initialized.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10559#add-comment?atlOrigin=eyJpIjoiMWY1OTNkZTc2OGY2NGM0MWI5NDIyMDBjMWNjZjExNjkiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10559#add-comment?atlOrigin=eyJpIjoiMWY1OTNkZTc2OGY2NGM0MWI5NDIyMDBjMWNjZjExNjkiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100201- 
sha1:92d0e2d )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] REST API no longer working on main?

[Gabriel Roldan]

I can't replicate with latest main so far (running web-app's Start from
eclipse).
What operation are you referring to? and which maven profiles are enabled?

may be unrelated, but the first answer here [1] lead me to search for
@Controller
annotated classes,
and found that RestConfigurationLockCallback is annotated with @Controller,
where it should be just @Component.

In that SO answer they also mention using @RestControllerAdvice instead
of @ControllerAdvice. We have 46 of the later,
none of the former. Might be a hint?

[1]
https://stackoverflow.com/questions/18813615/how-to-avoid-the-circular-view-path-exception-with-spring-mvc-test


On Fri, 15 Apr 2022 at 12:14, Andrea Aime 
wrote:

> Hi,
> the REST API does not seem to be working anymore on the main branch,
> I get the same exception both locally and on other demo servers (using
> Tomcat and the latest GeoServer nightly build):
>
> javax.servlet.ServletException: Circular view path [rest]: would dispatch 
> back to the current handler URL [/geoserver/rest] again. Check your 
> ViewResolver setup! (Hint: This may be the result of an unspecified view, due 
> to default view name generation.)
>   at 
> org.springframework.web.servlet.view.InternalResourceView.prepareForRendering(InternalResourceView.java:210)
>   at 
> org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:148)
>   at 
> org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:316)
>   at 
> org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1376)
>   at 
> org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1121)
>   at 
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1060)
>   at 
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
>   at 
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
>   at 
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
>   at 
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>   at 
> org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1459)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1631)
>   
>
> And here is the equivalent trace from a Tomcat deploy:
>
> javax.servlet.ServletException: Circular view path [rest]: would dispatch 
> back to the current handler URL [/geoserver/rest] again. Check your 
> ViewResolver setup! (Hint: This may be the result of an unspecified view, due 
> to default view name generation.)
>   
> org.springframework.web.servlet.view.InternalResourceView.prepareForRendering(InternalResourceView.java:210)
>   
> org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:148)
>   
> org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:316)
>   
> org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1376)
>   
> org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1121)
>   
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1060)
>   
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
>   
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
>   
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:655)
>   
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
>   org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
>   
> org.geoserver.filters.ThreadLocalsCleanupFilter.doFilter(ThreadLocalsCleanupFilter.java:28)
>   
> org.geoserver.filters.SpringDelegatingFilter$Chain.doFilter(SpringDelegatingFilter.java:73)
>
> So it does not seem container dependent...
> At first I thought, this may be the Spring upgrade... but turns out, the
> REST API is working
> fine on 2.20.x (again, Tomcat + latest build).
>
> I quickly looked through the latest commits but I don't see anything
> obvious that might cause this behavior... and yet, what caused it should be
> pretty recent, I was using the REST API on main, without issues, one or two
> days ago
>
> Is the above error ringing any bell to anyone?
>
> Cheers
> Andrea
>
> ==
>
> GeoServer Professional Services 

[Geoserver-devel] [JIRA] (GEOS-10445) Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiZmM3MmE4ZmQ0YjVkNDc1MzkwMTM0MWY4ZmViYjJmY2MiLCJwIjoiaiJ9
 ) / Task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10445?atlOrigin=eyJpIjoiZmM3MmE4ZmQ0YjVkNDc1MzkwMTM0MWY4ZmViYjJmY2MiLCJwIjoiaiJ9
 ) GEOS-10445 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10445?atlOrigin=eyJpIjoiZmM3MmE4ZmQ0YjVkNDc1MzkwMTM0MWY4ZmViYjJmY2MiLCJwIjoiaiJ9
 ) Upgrade springframework from 5.1.20.RELEASE to 5.2.20.RELEASE ( 
https://osgeo-org.atlassian.net/browse/GEOS-10445?atlOrigin=eyJpIjoiZmM3MmE4ZmQ0YjVkNDc1MzkwMTM0MWY4ZmViYjJmY2MiLCJwIjoiaiJ9
 )

Issue Type: Task Assignee: Unassigned Created: 01/Apr/22 4:22 PM Priority: 
Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-10445#add-comment?atlOrigin=eyJpIjoiZmM3MmE4ZmQ0YjVkNDc1MzkwMTM0MWY4ZmViYjJmY2MiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10445#add-comment?atlOrigin=eyJpIjoiZmM3MmE4ZmQ0YjVkNDc1MzkwMTM0MWY4ZmViYjJmY2MiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100197- 
sha1:666e164 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10425) NullPointerException on new AbstractAccessRuleDAO.lock() method

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNmMwN2RlN2QwZWRmNDRhMDg1MDU5OTQ4MmY5MDExYWIiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10425?atlOrigin=eyJpIjoiNmMwN2RlN2QwZWRmNDRhMDg1MDU5OTQ4MmY5MDExYWIiLCJwIjoiaiJ9
 ) GEOS-10425 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10425?atlOrigin=eyJpIjoiNmMwN2RlN2QwZWRmNDRhMDg1MDU5OTQ4MmY5MDExYWIiLCJwIjoiaiJ9
 ) NullPointerException on new AbstractAccessRuleDAO.lock() method ( 
https://osgeo-org.atlassian.net/browse/GEOS-10425?atlOrigin=eyJpIjoiNmMwN2RlN2QwZWRmNDRhMDg1MDU5OTQ4MmY5MDExYWIiLCJwIjoiaiJ9
 )

Issue Type: Bug Assignee: Niels Charlier ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A1d2c4019-de4e-4624-8b27-2486941601cf
 ) Created: 19/Mar/22 1:57 AM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

https://osgeo-org.atlassian.net/browse/GEOS-10390 introduced a new method,

AbstractAccessRuleDAO.lock()

as part of https://github.com/geoserver/geoserver/pull/5705

which unconditionally calls in the watcher instance variable, which can be 
null, when SecuredResourceNameChangeListener calls dao.lock():

public Lock lock() {
return watcher.getResource().lock();
}

It all works only if there’s a security folder.

The other method that uses that variable does perform a null check:

public boolean isModified() {
   return watcher != null && watcher.isStale();
}

( 
https://osgeo-org.atlassian.net/browse/GEOS-10425#add-comment?atlOrigin=eyJpIjoiNmMwN2RlN2QwZWRmNDRhMDg1MDU5OTQ4MmY5MDExYWIiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10425#add-comment?atlOrigin=eyJpIjoiNmMwN2RlN2QwZWRmNDRhMDg1MDU5OTQ4MmY5MDExYWIiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100197- 
sha1:003460b )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] teradata downgrade to community breaks the build on empty local m2 repo

[Gabriel Roldan]

Hi,

I'm getting a build failure on `main`, apparently only if the old teradata
jar is not in the local maven repo (e.g. rm -rf
~/.m2/repository/org/geoserver first).

And wonder why the builds didn't fail for
https://github.com/geoserver/geoserver/pull/5688

Maybe it's getting it from the maven cache.

In any case I've checked there's no other pom under community having
extension as parent just to make sure I'm not missing anything, and created
this pr: https://github.com/geoserver/geoserver/pull/5696


mvn clean install -DskipTests -PallExtensions,communityRelease
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'parent.relativePath' of POM
org.geoserver.community:gs-teradata:2.21-SNAPSHOT
(/data2/groldan/git/geoserver/geoserver/master/src/community/teradata/pom.xml)
points at org.geoserver:community instead of org.geoserver:extension,
please verify your project structure @ line 10, column 11
[FATAL] Non-resolvable parent POM for
org.geoserver.community:gs-teradata:2.21-SNAPSHOT: Could not find artifact
org.geoserver:extension:pom:2.21-SNAPSHOT and 'parent.relativePath' points
at wrong local POM @ line 10, column 11
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project org.geoserver.community:gs-teradata:2.21-SNAPSHOT
(/data2/groldan/git/geoserver/geoserver/master/src/community/teradata/pom.xml)
has 1 error
[ERROR] Non-resolvable parent POM for
org.geoserver.community:gs-teradata:2.21-SNAPSHOT: Could not find artifact
org.geoserver:extension:pom:2.21-SNAPSHOT and 'parent.relativePath' points
at wrong local POM @ line 10, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException



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

Re: [Geoserver-devel] Default value for Layer abstracts

[Gabriel Roldan]

Indeed, looks like misbehavior in both cases IMHO though.

Can't speak for the PSC, but my community vote goes for getting rid of that
hardcoding.

Cheers,

On Mon, 31 Jan 2022 at 20:04, Justin Deoliveira  wrote:

> Thanks Gabriel, nice to hear from you too!
>
> You're right in that for layer groups this has always been the behavior.
> What I think happened in the recent i18n refactor was that some code was
> refactored to share the encoding of the title and abstract for LayerInfo
> and LayerGroupInfo, and in doing so changed the behavior for single layers
> (non layer-group). I believe this was the change in that commit that did it:
>
>
> https://github.com/geoserver/geoserver/commit/3ea0b9817a4f1264c815d874ae612bf5e6d6fea4#diff-ce88fe929a6cf41c007f131c83eae16caedb0e849ccc0ccfe2ddcec7bdaead3cL1003
>
>
> On Mon, Jan 31, 2022 at 11:33 AM Gabriel Roldan 
> wrote:
>
>> Hey man, nice to hear from you.
>>
>> That seems strange actually, but couldn't track down when it was added,
>> it's already there at the first
>> git commit (44bacafcf1) in June 2011, so it's from the svn days.
>>
>> Wait, yeah, been like that since 2007 at least:
>> https://github.com/geoserver/geoserver-history/commit/9ab43af58a#diff-26d7a2ab35bebf3788e69ccb99b9722baf3a0fdb72f65278c620b6a80803dc49R964
>>
>> That said, it makes all sense to me to remove it and emit an empty
>> element instead.
>>
>> Cheers!
>>
>> On Mon, 31 Jan 2022 at 14:07, Justin Deoliveira 
>> wrote:
>>
>>> Howdy folks,
>>>
>>> First off amazing job on the project, great to see GeoServer thriving
>>> and be such a robust and stable tool, kudos to all of the core developers
>>> for their hard work.
>>>
>>> I have a question about a change that I am seeing after upgrading a
>>> Geoserver instance from a 2.18.x to the latest stable 2.20.x, with regards
>>> to layer abstracts in the WMS capabilities document. I wanted to check here
>>> whether it's considered a bug or not before I file a ticket, or work on a
>>> patch. The issue in question I believe traces back to the recent work done
>>> to allow for i18n of the capabilities document:
>>>
>>> - Pre-change, when a layer had no abstract the element would show up as
>>> empty in the capabilities document.
>>> - Post-change, the abstract gets a default value of "Layer-Group type
>>> layer: "
>>>
>>> I guess my ultimate question is whether this is desirable behavior? I am
>>> thinking an abstract referencing "Layer-Group" in the cases where it's not
>>> a layer group is perhaps an oversight.
>>>
>>> The bigger question is whether it's desirable to have a fallback value
>>> at all. In the case of the project I am working on there is an application
>>> that displays those abstracts to the user, which after the upgrade started
>>> to get a bit confusing with all of the default abstracts in there. I
>>> imagine there are GIS clients and web applications powered by GeoServer
>>> that do the same, which is why I wanted to ask.
>>>
>>> Thanks GeoServer crew!
>>>
>>> Justin
>>>
>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>>
>> --
>> Gabriel Roldán
>>
>

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

Re: [Geoserver-devel] Default value for Layer abstracts

[Gabriel Roldan]

Hey man, nice to hear from you.

That seems strange actually, but couldn't track down when it was added,
it's already there at the first
git commit (44bacafcf1) in June 2011, so it's from the svn days.

Wait, yeah, been like that since 2007 at least:
https://github.com/geoserver/geoserver-history/commit/9ab43af58a#diff-26d7a2ab35bebf3788e69ccb99b9722baf3a0fdb72f65278c620b6a80803dc49R964

That said, it makes all sense to me to remove it and emit an empty element
instead.

Cheers!

On Mon, 31 Jan 2022 at 14:07, Justin Deoliveira  wrote:

> Howdy folks,
>
> First off amazing job on the project, great to see GeoServer thriving and
> be such a robust and stable tool, kudos to all of the core developers for
> their hard work.
>
> I have a question about a change that I am seeing after upgrading a
> Geoserver instance from a 2.18.x to the latest stable 2.20.x, with regards
> to layer abstracts in the WMS capabilities document. I wanted to check here
> whether it's considered a bug or not before I file a ticket, or work on a
> patch. The issue in question I believe traces back to the recent work done
> to allow for i18n of the capabilities document:
>
> - Pre-change, when a layer had no abstract the element would show up as
> empty in the capabilities document.
> - Post-change, the abstract gets a default value of "Layer-Group type
> layer: "
>
> I guess my ultimate question is whether this is desirable behavior? I am
> thinking an abstract referencing "Layer-Group" in the cases where it's not
> a layer group is perhaps an oversight.
>
> The bigger question is whether it's desirable to have a fallback value at
> all. In the case of the project I am working on there is an application
> that displays those abstracts to the user, which after the upgrade started
> to get a bit confusing with all of the default abstracts in there. I
> imagine there are GIS clients and web applications powered by GeoServer
> that do the same, which is why I wanted to ask.
>
> Thanks GeoServer crew!
>
> Justin
>
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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

[Geoserver-devel] [JIRA] (GEOS-10375) jdbcconfig does not support WMTSStoreInfo and WMTSLayerInfo

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiYjY5NzEwMmUzNmMxNDZiNWI3YWQ3YmM0ZmIxOWI3NzMiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10375?atlOrigin=eyJpIjoiYjY5NzEwMmUzNmMxNDZiNWI3YWQ3YmM0ZmIxOWI3NzMiLCJwIjoiaiJ9
 ) GEOS-10375 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10375?atlOrigin=eyJpIjoiYjY5NzEwMmUzNmMxNDZiNWI3YWQ3YmM0ZmIxOWI3NzMiLCJwIjoiaiJ9
 ) jdbcconfig does not support WMTSStoreInfo and WMTSLayerInfo ( 
https://osgeo-org.atlassian.net/browse/GEOS-10375?atlOrigin=eyJpIjoiYjY5NzEwMmUzNmMxNDZiNWI3YWQ3YmM0ZmIxOWI3NzMiLCJwIjoiaiJ9
 )

Issue Type: Bug Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 30/Jan/22 7:19 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

the jdbcconfig catalog backend does not support WMTSStoreInfo and WMTSLayerInfo.

They can be added to the catalog due to the generic CatalogInfo handling inside 
jdbcconfig’s ConfigDatabase, but then can’t be queried as it lacks support for 
mapping properties of those types.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10375#add-comment?atlOrigin=eyJpIjoiYjY5NzEwMmUzNmMxNDZiNWI3YWQ3YmM0ZmIxOWI3NzMiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10375#add-comment?atlOrigin=eyJpIjoiYjY5NzEwMmUzNmMxNDZiNWI3YWQ3YmM0ZmIxOWI3NzMiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100189- 
sha1:09895c1 )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10374) Log exception flooding opening GWC's NewCachedLayerPage

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNzQ1ODEwYTc1M2NmNDg1Zjg4Yzg4YTMyZmEwMDI2ODgiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10374?atlOrigin=eyJpIjoiNzQ1ODEwYTc1M2NmNDg1Zjg4Yzg4YTMyZmEwMDI2ODgiLCJwIjoiaiJ9
 ) GEOS-10374 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10374?atlOrigin=eyJpIjoiNzQ1ODEwYTc1M2NmNDg1Zjg4Yzg4YTMyZmEwMDI2ODgiLCJwIjoiaiJ9
 ) Log exception flooding opening GWC's NewCachedLayerPage ( 
https://osgeo-org.atlassian.net/browse/GEOS-10374?atlOrigin=eyJpIjoiNzQ1ODEwYTc1M2NmNDg1Zjg4Yzg4YTMyZmEwMDI2ODgiLCJwIjoiaiJ9
 )

Issue Type: Bug Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 30/Jan/22 2:44 AM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

Every time “New Cached Layer” page is opened, the below is logged, flooding the 
logs. Does not prevent the page from working.

A problem occurred while checking object with type: 
org.geoserver.gwc.web.layer.UnconfiguredCachedLayersProvider$CachedSize
Field hierarchy is:
 7 [class=org.geoserver.gwc.web.layer.NewCachedLayerPage, path=7]
   private java.lang.Object org.apache.wicket.MarkupContainer.children 
[class=java.util.ArrayList]
 private java.io.Serializable 
org.apache.wicket.model.Model.object[write:89][write:91] 
[class=org.geoserver.web.wicket.GeoServerTablePanel, path=7:table]
   private java.lang.Object org.apache.wicket.MarkupContainer.children 
[class=java.util.ArrayList]
 private java.lang.Object 
org.apache.wicket.MarkupContainer.children[write:1] 
[class=org.apache.wicket.markup.html.form.Form, path=7:table:filterForm]
   private java.lang.Object org.apache.wicket.MarkupContainer.children 
[class=java.util.ArrayList]
 private org.apache.wicket.model.IModel 
org.apache.wicket.markup.html.link.AbstractLink.bodyModel[write:12][write:13] 
[class=org.geoserver.web.wicket.GeoServerTablePanel$Pager, 
path=7:table:filterForm:navigatorTop]
   private java.lang.Object 
org.apache.wicket.MarkupContainer.children [class=java.util.ArrayList]
 private java.lang.Object 
org.apache.wicket.MarkupContainer.children[write:1] 
[class=org.geoserver.web.wicket.GeoServerPagingNavigator, 
path=7:table:filterForm:navigatorTop:navigator]
   private java.lang.Object 
org.apache.wicket.MarkupContainer.children [class=java.util.ArrayList]
 private java.lang.Object 
org.apache.wicket.MarkupContainer.children[write:1] 
[class=org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigation,
 path=7:table:filterForm:navigatorTop:navigator:navigation]
   private java.lang.Object 
org.apache.wicket.MarkupContainer.children 
[class=org.apache.wicket.markup.html.list.LoopItem, 
path=7:table:filterForm:navigatorTop:navigator:navigation:0]
 private java.lang.Object 
org.apache.wicket.MarkupContainer.children 
[class=org.apache.wicket.ajax.markup.html.navigation.paging.AjaxPagingNavigationLink,
 path=7:table:filterForm:navigatorTop:navigator:navigation:0:pageLink]
   protected final 
org.apache.wicket.markup.html.navigation.paging.IPageable 
org.apache.wicket.markup.html.navigation.paging.PagingNavigationLink.pageable 
[class=org.apache.wicket.markup.repeater.data.DataView, 
path=7:table:listContainer:items]
 private org.apache.wicket.MarkupContainer 
org.apache.wicket.Component.parent 
[class=org.apache.wicket.markup.html.WebMarkupContainer, 
path=7:table:listContainer]
   private java.lang.Object 
org.apache.wicket.MarkupContainer.children [class=java.util.ArrayList]
 private org.apache.wicket.model.IModel 
org.apache.wicket.markup.html.form.LabeledWebMarkupContainer.labelModel[write:3][write:6]
 [class=org.apache.wicket.markup.html.list.ListView, 
path=7:table:listContainer:sortableLinks]
   private java.lang.Object 
org.apache.wicket.MarkupContainer.children [class=java.util.ArrayList]
 private java.lang.Object 
org.apache.wicket.MarkupContainer.children[write:1] 
[class=org.apache.wicket.markup.html.list.ListItem, 
path=7:table:listContainer:sortableLinks:0]
   private java.lang.Object 
org.apache.wicket.MarkupContainer.children 
[class=org.apache.wicket.markup.html.panel.Fragment, 
path=7:table:listContainer:sortableLinks:0:header]
 private java.lang.Object 
org.apache.wicket.MarkupContainer.children 
[class

[Geoserver-devel] [JIRA] (GEOS-10371) NullPointerException logged when removing LayerGroup with null workspace

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiOWE3NWZhMzhjMWY3NDIyYTg3MTcxNjIwMTk1NTUxYjAiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10371?atlOrigin=eyJpIjoiOWE3NWZhMzhjMWY3NDIyYTg3MTcxNjIwMTk1NTUxYjAiLCJwIjoiaiJ9
 ) GEOS-10371 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10371?atlOrigin=eyJpIjoiOWE3NWZhMzhjMWY3NDIyYTg3MTcxNjIwMTk1NTUxYjAiLCJwIjoiaiJ9
 ) NullPointerException logged when removing LayerGroup with null workspace ( 
https://osgeo-org.atlassian.net/browse/GEOS-10371?atlOrigin=eyJpIjoiOWE3NWZhMzhjMWY3NDIyYTg3MTcxNjIwMTk1NTUxYjAiLCJwIjoiaiJ9
 )

Issue Type: Bug Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 26/Jan/22 8:16 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

SecuredResourceNameChangeListener doesn’t check if a LayerGroup.getWorkspace() 
is null, resuling in an NPE, logged as a warning:

26 Jan 16:13:06 WARN [catalog.impl] - Catalog listener threw exception handling 
event.
java.lang.NullPointerException
at 
org.geoserver.security.SecuredResourceNameChangeListener.handleRemoveEvent(SecuredResourceNameChangeListener.java:62)
at org.geoserver.catalog.impl.CatalogImpl.event(CatalogImpl.java:1882)
at 
org.geoserver.catalog.impl.CatalogImpl.fireRemoved(CatalogImpl.java:1871)
at org.geoserver.catalog.impl.CatalogImpl.removed(CatalogImpl.java:1819)
at org.geoserver.catalog.impl.CatalogImpl.remove(CatalogImpl.java:1128)
at 
org.geoserver.security.SecureCatalogImpl.remove(SecureCatalogImpl.java:1452)
at 
org.geoserver.catalog.impl.AbstractFilteredCatalog.remove(AbstractFilteredCatalog.java:760)
at 
org.geoserver.catalog.impl.AbstractCatalogDecorator.remove(AbstractCatalogDecorator.java:515)
at 
org.geoserver.catalog.impl.LocalWorkspaceCatalog.remove(LocalWorkspaceCatalog.java:424)
at 
org.geoserver.catalog.CascadeDeleteVisitor.visit(CascadeDeleteVisitor.java:381)
at 
org.geoserver.security.decorators.DecoratingLayerGroupInfo.accept(DecoratingLayerGroupInfo.java:191)
at 
org.geoserver.web.data.SelectionRemovalLink$1.onSubmit(SelectionRemovalLink.java:71)
at 
org.geoserver.web.wicket.GeoServerDialog.submit(GeoServerDialog.java:148)
at 
org.geoserver.web.wicket.GeoServerDialog$1.onSubmit(GeoServerDialog.java:160)
at 
org.apache.wicket.ajax.markup.html.form.AjaxSubmitLink$1.onSubmit(AjaxSubmitLink.java:111)
at 
org.apache.wicket.ajax.form.AjaxFormSubmitBehavior$AjaxFormSubmitter.onSubmit(AjaxFormSubmitBehavior.java:218)
...

( 
https://osgeo-org.atlassian.net/browse/GEOS-10371#add-comment?atlOrigin=eyJpIjoiOWE3NWZhMzhjMWY3NDIyYTg3MTcxNjIwMTk1NTUxYjAiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10371#add-comment?atlOrigin=eyJpIjoiOWE3NWZhMzhjMWY3NDIyYTg3MTcxNjIwMTk1NTUxYjAiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100189- 
sha1:c51f787 )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10364) Duplicate bean definitions in gwc spring context config files

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiOThjMmE5MmNmYmRkNDUxZjkxZDYyODI0YjVmMWVhZDgiLCJwIjoiaiJ9
 ) / Task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10364?atlOrigin=eyJpIjoiOThjMmE5MmNmYmRkNDUxZjkxZDYyODI0YjVmMWVhZDgiLCJwIjoiaiJ9
 ) GEOS-10364 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10364?atlOrigin=eyJpIjoiOThjMmE5MmNmYmRkNDUxZjkxZDYyODI0YjVmMWVhZDgiLCJwIjoiaiJ9
 ) Duplicate bean definitions in gwc spring context config files ( 
https://osgeo-org.atlassian.net/browse/GEOS-10364?atlOrigin=eyJpIjoiOThjMmE5MmNmYmRkNDUxZjkxZDYyODI0YjVmMWVhZDgiLCJwIjoiaiJ9
 )

Issue Type: Task Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 24/Jan/22 2:10 AM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

There are 5 duplicate bean definitions in gs-gwc:

grep "
 
 
 
 
 
 

Ratioale being GWCServiceEnablementInterceptor checks delegates to 
gwcFacade.isServiceEnabled(service) , as shown bellow, and it’s not 
parameterized, so all those beans are the same:

   final org.geowebcache.service.Service service = (Service) 
invocation.getThis();
   boolean serviceEnabled;
   if (service.getPathName().equals("wmts")) {
   serviceEnabled = geoServer.getService(WMTSInfo.class).isEnabled();
   } else {
   serviceEnabled = gwcFacade.isServiceEnabled(service);
   }

Proposal is:

* Remove duplicate bean definitions

* Replace all GWCServiceEnablementInterceptor beans by a single one
* Refactor bean locations, several beans are defined in applicationContext.xml 
, which in turn imports geowebcache-servlet.xml and 
geowebcache-geoserver-context.xml , while geowebcache-servlet.xml imports all 
the regular GWC context files. Since there are 106 unique bean definitions in 
total, it’s hard to reason what goes where, so I’d like to have 
applicationContext.xml be just like:
 
 
 
 

instead of mixing up geoserver specific beans across applicationContext.xml and 
geowebcache-geoserver-context.xml

( 
https://osgeo-org.atlassian.net/browse/GEOS-10364#add-comment?atlOrigin=eyJpIjoiOThjMmE5MmNmYmRkNDUxZjkxZDYyODI0YjVmMWVhZDgiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10364#add-comment?atlOrigin=eyJpIjoiOThjMmE5MmNmYmRkNDUxZjkxZDYyODI0YjVmMWVhZDgiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100189- 
sha1:399499b )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10348) Remove unnecessary dependeny on com.h2database:h2 from gs-platform

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiYTQ4MGVkMDk1MDE2NDZmN2I3ZDJlMzcxMDJlZjMyYWQiLCJwIjoiaiJ9
 ) / Task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10348?atlOrigin=eyJpIjoiYTQ4MGVkMDk1MDE2NDZmN2I3ZDJlMzcxMDJlZjMyYWQiLCJwIjoiaiJ9
 ) GEOS-10348 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10348?atlOrigin=eyJpIjoiYTQ4MGVkMDk1MDE2NDZmN2I3ZDJlMzcxMDJlZjMyYWQiLCJwIjoiaiJ9
 ) Remove unnecessary dependeny on com.h2database:h2 from gs-platform ( 
https://osgeo-org.atlassian.net/browse/GEOS-10348?atlOrigin=eyJpIjoiYTQ4MGVkMDk1MDE2NDZmN2I3ZDJlMzcxMDJlZjMyYWQiLCJwIjoiaiJ9
 )

Issue Type: Task Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 06/Jan/22 2:48 AM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

gs-platform depends on H2 but it doesn’t need it.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10348#add-comment?atlOrigin=eyJpIjoiYTQ4MGVkMDk1MDE2NDZmN2I3ZDJlMzcxMDJlZjMyYWQiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10348#add-comment?atlOrigin=eyJpIjoiYTQ4MGVkMDk1MDE2NDZmN2I3ZDJlMzcxMDJlZjMyYWQiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100187- 
sha1:07b4f58 )
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Time to remove the geogig community module?

[Gabriel Roldan]

+1 iirc I wanted to remove it a long time ago

El dom., 19 de diciembre de 2021 16:02, Ian Turton 
escribió:

> +1
>
> On Sun, 19 Dec 2021, 16:56 Nuno Oliveira, <
> nuno.olive...@geosolutionsgroup.com> wrote:
>
>> +1
>>
>> On Sun, Dec 19, 2021 at 4:06 PM Simone Giannecchini <
>> simone.giannecch...@geosolutionsgroup.com> wrote:
>>
>>> As far as I am concerned, I am +1.
>>>
>>> Regards,
>>> Simone Giannecchini
>>> ==
>>> GeoServer Professional Services from the experts!
>>> Visit http://bit.ly/gs-services for more information.
>>> ==
>>> Ing. Simone Giannecchini
>>> @simogeo
>>> Founder/Director GeoSolutions Italy
>>> President GeoSolutions USA
>>>
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob:   +39  333 8128928
>>>
>>> http://www.geosolutionsgroup.com
>>> http://twitter.com/geosolutions_it
>>>
>>> ---
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.
>>>
>>>
>>> On Sat, Dec 18, 2021 at 10:00 AM Andrea Aime <
>>> andrea.a...@geosolutionsgroup.com> wrote:
>>>
 Hi,
 today I was looking at which modules are still using gt-geojson (to
 switch them to gt-geojsondatastore) and  "git grep" found, among others,
 community/geogig.

 Looking into it, I've found out:

- It's actually not in the community build anymore
- geogig depends itself on gt-geojson, and has been last built
against GeoTools 26.x
- geogig has not seen a new release in three years (last is Nov
2018)

 My guess is, it's time to remove the integration module from the
 GeoServer sources... but I'd like to hear from the community, and in
 particular Gabriel, before getting there.

 Cheers
 Andrea
 ==

 GeoServer Professional Services from the experts!

 Visit http://bit.ly/gs-services-us for more information.
 ==

 Ing. Andrea Aime
 @geowolf
 Technical Lead

 GeoSolutions Group
 phone: +39 0584 962313

 fax: +39 0584 1660272

 mob:   +39  333 8128928

 https://www.geosolutionsgroup.com/

 http://twitter.com/geosolutions_it

 ---

 Con riferimento alla normativa sul trattamento dei dati personali (Reg.
 UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
 precisa che ogni circostanza inerente alla presente email (il suo
 contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
 riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
 messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
 operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

 This email is intended only for the person or entity to which it is
 addressed and may contain information that is privileged, confidential or
 otherwise protected from disclosure. We remind that - as provided by
 European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
 e-mail or the information herein by anyone other than the intended
 recipient is prohibited. If you have received this email by mistake, please
 notify us immediately by telephone or e-mail
 ___
 Geoserver-devel mailing list
 Geoserver-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/geoserver-devel

>>> ___
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>
>>
>> --
>>
>> Regards,
>>
>> Nuno Oliveira
>>
>> ==
>> GeoServer Professional Services from the experts!
>>
>> Visit http://bit.ly/gs-services-us for more information.
>> ==
>>
>> Nuno Miguel Carvalho Oliveira
>> @nmcoliveira
>> Technical Lead / Project Manager
>>
>>
>> GeoSolutions Group
>> phone: +39 0584 962313
>> fax:  +39 0584 1660272
>>
>> https://www.geosolutionsgroup.com/
>> http://twitter.com/geosolutions_it
>> ---
>>
>>
>> Con riferimento alla normativa sul trattamento dei dati personali (Reg.
>> UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>> precisa che ogni circostanza inerente alla presente email (il suo
>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>> 

[Geoserver-devel] [JIRA] (GEOS-10134) Dead code: CatalogFactory.create(Class)

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMDU1ZjBjYWRlZTNiNGJiZGExZWNjY2U2ZTUyNTI2ZTkiLCJwIjoiaiJ9
 ) / Task ( 
https://osgeo-org.atlassian.net/browse/GEOS-10134?atlOrigin=eyJpIjoiMDU1ZjBjYWRlZTNiNGJiZGExZWNjY2U2ZTUyNTI2ZTkiLCJwIjoiaiJ9
 ) GEOS-10134 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10134?atlOrigin=eyJpIjoiMDU1ZjBjYWRlZTNiNGJiZGExZWNjY2U2ZTUyNTI2ZTkiLCJwIjoiaiJ9
 ) Dead code: CatalogFactory.create(Class) ( 
https://osgeo-org.atlassian.net/browse/GEOS-10134?atlOrigin=eyJpIjoiMDU1ZjBjYWRlZTNiNGJiZGExZWNjY2U2ZTUyNTI2ZTkiLCJwIjoiaiJ9
 )

Issue Type: Task Affects Versions: 2.19.1 Assignee: Unassigned Components: Main 
Created: 06/Jul/21 1:24 AM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

Stumbled upon this dead code in CatalogFactory / Impl. Should we just remove it?

CatalogFactory :

   /**
* Extensible factory method.
*
* This method should lookup the appropritae instance of {@link 
Extension} to create the
* object. The lookup mechanism is specific to the runtime environement.
*
* @param clazz The class of object to create.
* @return The new object.
*/
T create(Class clazz);

   /** Factory extension. */
   interface Extension {

   /**
* Determines if the extension can create objects of the specified class.
*
* @param clazz The class of object to create.
*/
boolean canCreate(Class clazz);

   /**
* Creates an instance of the specified class.
*
* This method is only called if {@link #canCreate(Class)} returns 
true.
*
* @param clazz The class of object to create.
* @param context A context to initialize the object.
* @return The new object.
*/
T create(Class clazz, Map context);
   }

CatalogFactoryImpl :

   public  T create(Class clazz) {
   return null;
   }

( 
https://osgeo-org.atlassian.net/browse/GEOS-10134#add-comment?atlOrigin=eyJpIjoiMDU1ZjBjYWRlZTNiNGJiZGExZWNjY2U2ZTUyNTI2ZTkiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10134#add-comment?atlOrigin=eyJpIjoiMDU1ZjBjYWRlZTNiNGJiZGExZWNjY2U2ZTUyNTI2ZTkiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100168- 
sha1:f27f540 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] [Geotools-devel] PMD complexity checks... "cognitive complexity"

[Gabriel Roldan]

Hey Andrea, that looks great.
Is it complementary with the ExcessiveMethodLength rule or surpasses it?

This reminded me I had these unpushed branches. Created a jira ticket and
these pr's:

https://github.com/geotools/geotools/pull/3544
https://github.com/geotools/geotools/pull/3545
https://github.com/geotools/geotools/pull/3546


On Sat, 12 Jun 2021 at 09:02, Roar Brænden 
wrote:

> Good points, but I have spent a lot of time figuring out
> NullPointerException within Geotools.
>
> Regards,
>
> Roar Brænden
>
> lør. 12. jun. 2021 kl. 13:29 skrev Andrea Aime <
> andrea.a...@geo-solutions.it>:
>
>> On Sat, Jun 12, 2021 at 12:31 PM Roar Brænden 
>> wrote:
>>
>>> Hi,
>>> Looking at that last method, I counted seven «return null».
>>> Is there a PMD for replacing «return null» with Optional?
>>>
>>
>> I don't know.. but that would be an API break. So it needs the usual
>> cycle of deprecation,
>> replacement, removal after a release.
>>
>> Also, it must not be subject to a dumb automatic check, there is a lot of
>> discussion on the
>> net about usage of Optionals, inlcuding a list of places where they
>> should not be used... a few
>> of interesting refences:
>> -
>> https://medium.com/@yassinhajaj/optionals-are-bad-practices-still-bad-practices-if-everyone-practices-them-6ec5a66c30aa
>> - https://dzone.com/articles/using-optional-correctly-is-not-optional
>>
>> In the specific case of GeoTools, using Optionals should be taken with
>> extra care, as we
>> have parts of the API called millions of times, adding the allocation of
>> millions of wrappers
>> causes significant overhead (as we have learned the hard and painful way
>> with the JTS Coordinate class).
>>
>> Cheers
>> Andrea
>>
>> == GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>> --- *Con riferimento
>> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
>> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
>> circostanza inerente alla presente email (il suo contenuto, gli eventuali
>> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
>> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
>> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
>> sarei comunque grato se potesse darmene notizia. This email is intended
>> only for the person or entity to which it is addressed and may contain
>> information that is privileged, confidential or otherwise protected from
>> disclosure. We remind that - as provided by European Regulation 2016/679
>> “GDPR” - copying, dissemination or use of this e-mail or the information
>> herein by anyone other than the intended recipient is prohibited. If you
>> have received this email by mistake, please notify us immediately by
>> telephone or e-mail.*
>>
> ___
> GeoTools-Devel mailing list
> geotools-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


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

[Geoserver-devel] [JIRA] (GEOS-10109) Excessive (500+) method lengths. Add a PMD rule to enforce it.

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiYzI2ZjViN2VlZGY4NGQ4MWIyNDI3YjRjYTIzYzEyYzAiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10109?atlOrigin=eyJpIjoiYzI2ZjViN2VlZGY4NGQ4MWIyNDI3YjRjYTIzYzEyYzAiLCJwIjoiaiJ9
 ) GEOS-10109 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10109?atlOrigin=eyJpIjoiYzI2ZjViN2VlZGY4NGQ4MWIyNDI3YjRjYTIzYzEyYzAiLCJwIjoiaiJ9
 ) Excessive (500+) method lengths. Add a PMD rule to enforce it. ( 
https://osgeo-org.atlassian.net/browse/GEOS-10109?atlOrigin=eyJpIjoiYzI2ZjViN2VlZGY4NGQ4MWIyNDI3YjRjYTIzYzEyYzAiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Unassigned Created: 12/Jun/21 3:20 PM 
Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

https://pmd.github.io/latest/pmd_rules_plsql_design.html#excessivemethodlength

This QA metric is primarily related to the difficulty to follow code paths on 
too large methods. Both for the original author and others.
Excessive method length speaks also of a bad internal design for a class.
Ideally, a method should do one single thing, at a given abstraction level, and 
defer lowe level implementation details to other, properly named methods, and 
so on, in a way that at a glance, a reader can figure out what a method does, 
and drill down to more and more implementation detail only if needed.

The PMD rule's default threshold is 100 lines of code. We have way too many 
methods over that count to tackle it in a single shot.
Setting an initial value of *500* leaves us with the 4 biggest offenders. 
Please check this assessment for more information:

https://github.com/groldan/geoserver/wiki/ExcessiveMethodLength-PMD-assessment---GeoServer

( 
https://osgeo-org.atlassian.net/browse/GEOS-10109#add-comment?atlOrigin=eyJpIjoiYzI2ZjViN2VlZGY4NGQ4MWIyNDI3YjRjYTIzYzEyYzAiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10109#add-comment?atlOrigin=eyJpIjoiYzI2ZjViN2VlZGY4NGQ4MWIyNDI3YjRjYTIzYzEyYzAiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100166- 
sha1:25236ce )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] [JIRA] (GEOS-10106) Remove direct dependency on gs-platform and gt-cql from all community modules

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiMWE5YTY5MGI0ZjdjNDRlNGExODkwMDU5N2IwM2NjMTUiLCJwIjoiaiJ9
 ) / Improvement ( 
https://osgeo-org.atlassian.net/browse/GEOS-10106?atlOrigin=eyJpIjoiMWE5YTY5MGI0ZjdjNDRlNGExODkwMDU5N2IwM2NjMTUiLCJwIjoiaiJ9
 ) GEOS-10106 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10106?atlOrigin=eyJpIjoiMWE5YTY5MGI0ZjdjNDRlNGExODkwMDU5N2IwM2NjMTUiLCJwIjoiaiJ9
 ) Remove direct dependency on gs-platform and gt-cql from all community 
modules ( 
https://osgeo-org.atlassian.net/browse/GEOS-10106?atlOrigin=eyJpIjoiMWE5YTY5MGI0ZjdjNDRlNGExODkwMDU5N2IwM2NjMTUiLCJwIjoiaiJ9
 )

Issue Type: Improvement Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Created: 11/Jun/21 4:38 PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

The root comunity modules pom ( src/community/pom.xml ) sets a direct 
dependency on gs-platform and gt-cql to all community modules.

This carries over a lot of transitive dependencies (including spring, geotools, 
jai, emf, etc).

Some may not need to depend on those. For example, the gs-rest-openapi client 
library.

( 
https://osgeo-org.atlassian.net/browse/GEOS-10106#add-comment?atlOrigin=eyJpIjoiMWE5YTY5MGI0ZjdjNDRlNGExODkwMDU5N2IwM2NjMTUiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10106#add-comment?atlOrigin=eyJpIjoiMWE5YTY5MGI0ZjdjNDRlNGExODkwMDU5N2IwM2NjMTUiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100166- 
sha1:25236ce )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Interesting bit from OGC API - Tiles... storing meta-info about tiles?

[Gabriel Roldan]

If that's all the meta info to store, anything not in the tile file itself
would be overkill.
Looks like we only need 2 bits for a full/empty/unknown flag.
On Linux and MacOS it should be possible to use extended file attributes,
dunno about Windows.
I'm pretty sure S3 also supports custom object metadata.

Not fond of the idea of side-car files, though could be an opt-in
compromise due to overhead (would require a check for existence for all
tiles).

2c.


On Thu, 27 May 2021 at 07:47, Andrea Aime 
wrote:

> Hi all,,
> while reviewing the OGC API Tiles spec, found these bits about returning
> HTTP headers,
> telling the client that a given portion of the tile cache might be fully
> empty, or completely solid,
> from that point on:
>
>
> https://github.com/opengeospatial/ogcapi-tiles/blob/master/core/standard/recommendations/tileset/REC_tc-deepfullempty.adoc
>
> If we had to implement this (it's just a recommendation) then we'd need to
> store meta-information around
> the tile, something the BlobStore interface and TileObject have no room
> for right now.
>
> FileBlobStore/AWS wise I guess sidecar files could be used... for some
> formats headers could be an option too,
> but don't think every tile format allows for that option, or might have
> limitation regarding the type and size
> of info that can be stored in the headers.
>
> Has anyone worked on something like this before?
>
> Cheers
> Andrea
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> --- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


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

[Geoserver-devel] [JIRA] (GEOS-10074) GeoFence "Admin rules" grant "ADMIN" access to unauthorized users

[Gabriel Roldan (JIRA)]

Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) *created* an issue

GeoServer ( 
https://osgeo-org.atlassian.net/browse/GEOS?atlOrigin=eyJpIjoiNTIwMTI0MmM5MDIzNGZjMDk0NzVjMjZhMzA0ZGVjMGYiLCJwIjoiaiJ9
 ) / Bug ( 
https://osgeo-org.atlassian.net/browse/GEOS-10074?atlOrigin=eyJpIjoiNTIwMTI0MmM5MDIzNGZjMDk0NzVjMjZhMzA0ZGVjMGYiLCJwIjoiaiJ9
 ) GEOS-10074 ( 
https://osgeo-org.atlassian.net/browse/GEOS-10074?atlOrigin=eyJpIjoiNTIwMTI0MmM5MDIzNGZjMDk0NzVjMjZhMzA0ZGVjMGYiLCJwIjoiaiJ9
 ) GeoFence "Admin rules" grant "ADMIN" access to unauthorized users ( 
https://osgeo-org.atlassian.net/browse/GEOS-10074?atlOrigin=eyJpIjoiNTIwMTI0MmM5MDIzNGZjMDk0NzVjMjZhMzA0ZGVjMGYiLCJwIjoiaiJ9
 )

Issue Type: Bug Affects Versions: 2.19.0 Assignee: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 ) Attachments: image-2021-05-21-15-27-39-296.png, 
image-2021-05-21-15-28-19-481.png Components: GeoFence Created: 21/May/21 8:28 
PM Priority: Medium Reporter: Gabriel Roldan ( 
https://osgeo-org.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A54db8b09-1e64-436a-adac-248049585cee
 )

Initially reported as a geofence issue ( 
https://github.com/geoserver/geofence/issues/140 ) about a year ago.

The mere existence of Admin Rules grant admin access to all workspaces for 
which an admin rule exists to all users.

To reproduce:

$ cp -rf data/release /tmp/data_dir
$ mvn -f src/web/app -Pgeofence-server \
-DGEOSERVER_DATA_DIR=/tmp/data_dir  \
-Djava.net.preferIPv4Stack=true \
jetty:run 

Create the following users and roles:

User Role sf_admin SF_ADMIN sf_user SF_USER topp_admin TOPP_ADMIN topp_user 
TOPP_USER

Set up the following GeoFence "Data Rules":
( 
https://osgeo-org.atlassian.net/secure/attachment/33706/33706_image-2021-05-21-15-27-39-296.png
 )

Set up the following GeoFence "Admin Rules":
( 
https://osgeo-org.atlassian.net/secure/attachment/33705/33705_image-2021-05-21-15-28-19-481.png
 )

( 
https://osgeo-org.atlassian.net/browse/GEOS-10074#add-comment?atlOrigin=eyJpIjoiNTIwMTI0MmM5MDIzNGZjMDk0NzVjMjZhMzA0ZGVjMGYiLCJwIjoiaiJ9
 ) Add Comment ( 
https://osgeo-org.atlassian.net/browse/GEOS-10074#add-comment?atlOrigin=eyJpIjoiNTIwMTI0MmM5MDIzNGZjMDk0NzVjMjZhMzA0ZGVjMGYiLCJwIjoiaiJ9
 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( 
https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core=utm_source%3DNotificationLink%26utm_medium%3DEmail
 ) or iOS ( 
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495=EmailNotificationLink=8
 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100162- 
sha1:2e82ed7 )___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel