Re: [Geoserver-devel] Eclipse Setup
Hi Jody, thanks for your explanations, that helps me. Regarding the IDE: Has the project agreed on the use of a different IDE or does everyone follow their personal preference? What do you think is used by the majority? -- Andreas Watermeyer ITS Digital Solutions GmbH Dillenburger Str. 77 | 51105 Köln +49 231 222 49 370 andreas.waterme...@its-digital.de www.its-digital.de Sitz der Gesellschaft: Dortmund, Amtsgericht Dortmund, HRB 28563 Geschäftsführer: Ludger Schulte, Gunnar Haack, Ralf Petersilka, Raimund Schipp, Heinrich Toben Von: Jody Garnett Gesendet: Samstag, 3. Februar 2024 05:52 An: Watermeyer, Andreas Cc: geoserver-devel@lists.sourceforge.net Betreff: Re: [Geoserver-devel] Eclipse Setup [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments. It has been a couple years since I used Eclipse IDE personally. I found it was important to do one run on the command line to make the generated code directories so the IDE could see them. For community modules we try and respect that they are experiments and ensure they compile (so take part in any refactoring) - but we do not offer them CPU cycles for testing on our build server (they are not stable enough to always pass tests). We know for the work ahead that OAuth community plugins need to be rewritten; if possible I would like to have one release cycle where new community module for OIDC is made alongside the older one to allow folks to migrate. But really for such an important component it difficult to understand why they have not attracted funding to be stable. So goal is: 1. include community module in refactor with the goal of compiling 2. Include community module in dependency upgrade with goal of compiling 3. When dependency upgrade cannot even compile (sigh) spend a few minuets to determine why, comment the plugin of the “release” profile, and notify the developer 1. How do you handle the extensions and the community modules Yes it does, I think this is why I stopped using Eclipse. 2. What do you do in case your changes on for example GS platform breaks community code or community tests. The priority is the code: do whatever you can to make it compile. If you really cannot get it to compile (say due to a dependency change) drop it from the build. The tests are not a priority at all, they are not included in the build. Your time as a volunteer is to be respected. 3. What is the expectation for the Jakarta EE migration regarding extensions and community code? Extensions are part of the GeoServer application and will be migrated. They are only optional to download, not optional to the GeoServer story. The module maintainer put enough enough tests to help us as maintainers just for situations like this. (We experienced this first hand with the big bad geotools refactor last year, the test coverage for GeoServer is really good and it makes the code much more maintainable). Community modules are experiments, and to be treated as such. There tests do not need to pass, or even be run. We have to respect our time as volunteers. 4. I wonder if you experience some specific problems, too and how you handle them a) In geofence: "The package javax.xml.namespace is accessible from more than one module: , java.xml". This causes a chain of compiler errors for me in Eclipse. Similar in other projects. During the api change last year we had to make a branch on the geofence project and work in parallel. The same for geowebcache, and mapfish-print-v2. b) Eclipse has trouble with "GeoServerTestSupport" because it is referenced tests of dependent projects, but it resides in gs-main/src/test/java, where it is not avaible for reuse. Normally it would expect that GeoServerTestSupport is in src/main/java of a test project or gs-main is an additional "test-jar" dependency. How do you handle that? I remember being able to add a test dependency or something in eclipse. It is unusual but maven supports doing so. c) Eclipse: Cannot nest "gs-rest-openapi-generated-feign-client/target/generated-sources/openapi/src/main/java" inside "gs-rest[...]". I would talk to Gabe about that - it looks very cool. I assume it is an integration test. A generated maven project that eclipse has picked up? I do not think you edit that code directly, somehow ignore it from Eclipse and trust the command line to run that integration test. Have a good weekend yourself. -- Jody Garnett On Fri, Feb 2, 2024 at 10:23 AM Watermeyer, Andreas <mailto:andreas.waterme...@its-digital.de> wrote: Hi community, I am trying to setup Eclipse 2023-12 with JDK 11 for the GeoServer project to support in the Jakarta EE migration. I use the main branch and I pretty much followed the developer guide. I have a couple of questions though: 1. How do you handle the extensions and the community modules: The w
[Geoserver-devel] Eclipse Setup
Hi community, I am trying to setup Eclipse 2023-12 with JDK 11 for the GeoServer project to support in the Jakarta EE migration. I use the main branch and I pretty much followed the developer guide. I have a couple of questions though: 1. How do you handle the extensions and the community modules: The workspace gets pretty big having all those projects open and Eclipse is quite slow especially on pom updates. Do you close the community module you are not responsible for? 2. What do you do in case your changes on for example GS platform breaks community code or community tests. Do you fix them? Or is the maintainer expected to jump in? 3. What is the expectation for the Jakarta EE migration regarding extensions and community code? 4. I wonder if you experience some specific problems, too and how you handle them. For example: a) In geofence: "The package javax.xml.namespace is accessible from more than one module: , java.xml". This causes a chain of compiler errors for me in Eclipse. Similar in other projects. b) Eclipse has trouble with "GeoServerTestSupport" because it is referenced tests of dependent projects, but it resides in gs-main/src/test/java, where it is not avaible for reuse. Normally it would expect that GeoServerTestSupport is in src/main/java of a test project or gs-main is an additional "test-jar" dependency. How do you handle that? c) Eclipse: Cannot nest "gs-rest-openapi-generated-feign-client/target/generated-sources/openapi/src/main/java" inside "gs-rest[...]". Thank you for your support and have a nice weekend! Andreas ITS Digital Solutions GmbH Dillenburger Str. 77 | 51105 Köln +49 231 222 49 370 andreas.waterme...@its-digital.de www.its-digital.de Sitz der Gesellschaft: Dortmund, Amtsgericht Dortmund, HRB 28563 Geschäftsführer: Ludger Schulte, Gunnar Haack, Ralf Petersilka, Raimund Schipp, Heinrich Toben ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] GeoServer spring-security upgrade
Hello community, as discussed with Jody and Andrea I can offer to work on the GeoServer spring-security 5.8 upgrade. I have created corresponding issues: * GEOS-11271: Upgrade spring-security to 5.8 [1] * GEOS-11272: spring-security-oauth replacement, with spring-security 5.8 [2] It would be nice if someone from the core team could confirm that I can start to ensure that no other people step in and to avoid misunderstandings. [1] https://osgeo-org.atlassian.net/browse/GEOS-11271 [2] https://osgeo-org.atlassian.net/browse/GEOS-11272 Best regards, Andreas ITS Digital Solutions GmbH Dillenburger Str. 77 | 51105 Köln +49 231 222 49 370 andreas.waterme...@its-digital.de www.its-digital.de Sitz der Gesellschaft: Dortmund, Amtsgericht Dortmund, HRB 28563 Geschäftsführer: Ludger Schulte, Gunnar Haack, Ralf Petersilka, Raimund Schipp, Heinrich Toben ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Security considerations for 2.24.0 and 2.23.2
Hi Jody, I think it is Ok when a release announcement initially contains an unspecific “security considerations” sections if that is justified and necessary: To me It means I have to keep an eye on that. But if an release announcement contains no security considerations at all I would assume that there is no security related reason to upgrade to this release and I would not check this announcement again. So: Do I have to expect the “security considerations” are added newly to a release announcement after it has be published, as it was done for 2.23.2 ? Thank you very much for taking care! Best regards, Andreas Watermeyer Von: Jody Garnett Gesendet: Samstag, 21. Oktober 2023 08:48 An: Watermeyer, Andreas Cc: geoserver-devel@lists.sourceforge.net Betreff: Re: [Geoserver-devel] Security considerations for 2.24.0 and 2.23.2 [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments. Hello, We have been updating our security policy, as we figure out how to inform folks of security vulnerabilities. It is hard to encourage people to update, without being in a position to tell why (yet). Please see GSIP-220 for the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-220 In the coming weeks (maybe at foss4gna) when I have time I will publish some CVE numbers that are presently in draft, and update the release announcement “security vulnerability” sections. But this really is when I have time, and I an quite exhausted :) Jody On Fri, Oct 20, 2023 at 2:28 AM Watermeyer, Andreas mailto:andreas.waterme...@its-digital.de>> wrote: Hello community, 1) reviewing the GeoServer security policy I found the approach of a "Coordinated vulnerability disclosure" very reasonable. Thanks for taking security seriously. Regarding: 4. A fix is included for the "stable" and "maintenance" downloads [...] Does that mean, that GeoServer 2.23.2 from 2023-07-21 already contains the security patches relevant for this release ? Or will there a 2.23.3 ? A backport would be useful in this situation because of the GeoTools API-package introduction, making it harder to upgrade. 2) I regularly check for new GeoServer releases and especially the "security considerations" in the release announcements. I am also keeping book of my activities. Result: I checked the GeoServer announcement for 2.23.2 from 2023-07-21 on 2023-08-21 (after my summer vacation :-) ) and I found NO security considerations for this release. Checking the same release *NOW* there *ARE* security considerations for this release. Current announcement for 2.23.2: https://geoserver.org/announcements/2023/07/21/geoserver-2-23-2-released.html Original announcement for 2.23.2:: http://web.archive.org/web/20230731072113/https://geoserver.org/announcements/2023/07/21/geoserver-2-23-2-released.html<http://web.archive.org/web/20230731072113/https:/geoserver.org/announcements/2023/07/21/geoserver-2-23-2-released.html> I suppose this happened by mistake or is this expected behavior? Best regards and have a nice weekend, Andreas Watermeyer ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net<mailto: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] Security considerations for 2.24.0 and 2.23.2
Hello community, 1) reviewing the GeoServer security policy I found the approach of a "Coordinated vulnerability disclosure" very reasonable. Thanks for taking security seriously. Regarding: 4. A fix is included for the "stable" and "maintenance" downloads [...] Does that mean, that GeoServer 2.23.2 from 2023-07-21 already contains the security patches relevant for this release ? Or will there a 2.23.3 ? A backport would be useful in this situation because of the GeoTools API-package introduction, making it harder to upgrade. 2) I regularly check for new GeoServer releases and especially the "security considerations" in the release announcements. I am also keeping book of my activities. Result: I checked the GeoServer announcement for 2.23.2 from 2023-07-21 on 2023-08-21 (after my summer vacation :-) ) and I found NO security considerations for this release. Checking the same release *NOW* there *ARE* security considerations for this release. Current announcement for 2.23.2: https://geoserver.org/announcements/2023/07/21/geoserver-2-23-2-released.html Original announcement for 2.23.2:: http://web.archive.org/web/20230731072113/https://geoserver.org/announcements/2023/07/21/geoserver-2-23-2-released.html I suppose this happened by mistake or is this expected behavior? Best regards and have a nice weekend, Andreas Watermeyer ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] CRS bbox for EPSG:3149 / Gauss-Krueger zone 5
Hi Jukka, Ok, I got that, thanks. And is it possible to adjust the bounds for a CRS in GeoServer? Currently WMS GetFeatureInfo stays empty when queried outside the extend of the CRS, although data is there. Best regards, Andreas -Ursprüngliche Nachricht- Von: Rahkonen Jukka Gesendet: Dienstag, 25. April 2023 11:42 An: Watermeyer, Andreas ; geoserver-devel@lists.sourceforge.net Betreff: VS: CRS bbox for EPSG:3149 / Gauss-Krueger zone 5 [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments. Hi, I do not know the history in the background, but for me it looks like the coordinate system itself is a normal 3 degree wide GK zone and transformations and conversions and whatever would mathematically work correctly over the whole 3 degree wide area. However, that national mapping agency has defined that code EPSG:31469 is only used in West Germany and more strict on the area of the state of Bayern. EPSG registry has registered the coordinate system based on that information. There is a change request from year 2006 "For areas 1625-27, removed former East German states." And in 2011 there is a change request "For CRSs 31466-69, added remarks regarding offshore geological survey usage" that expands the area of use as a description. So technically I would trust that EPSG:31469 can be used over the 3-degree area, but the BBOX that Geoserver shows is correct and matches with the information from EPSG and initially from the German authorities. The EPSG database has only place for ultimate N-S-E-W coordinates and therefore even the BBOX is larger than the real area of use, that follows the border between former West and East Germany. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Watermeyer, Andreas Lähetetty: tiistai 25. huhtikuuta 2023 12.08 Vastaanottaja: Rahkonen Jukka ; geoserver-devel@lists.sourceforge.net Aihe: AW: CRS bbox for EPSG:3149 / Gauss-Krueger zone 5 Hi Jukka, thanks for your response! I know that site - I find it also confusing. For what I can say the bbox mentioned there is too small, too. >From that site: Name: Germany - West Germany - east of 13.5°E Description: Germany - former West Germany onshore east of 13°30'E - state of Bayern. Extends: 13.5 ° - 13.84 °, 48.98 ° - 48.51 ° Conversion: 3-degree Gauss-Kruger zone 5 Remarks: Zone width 3 degrees. Also used offshore by State Geological Surveys So, to me is unclear: * why do "conversion" and "remarks" say it is a 3 degree width but the extend only cover 13.5 ° - 13.84 ° * what means "conversion" ? Thank you and best regards, Andreas -Ursprüngliche Nachricht- Von: Rahkonen Jukka Gesendet: Dienstag, 25. April 2023 09:50 An: Watermeyer, Andreas ; geoserver-devel@lists.sourceforge.net Betreff: Re: CRS bbox for EPSG:3149 / Gauss-Krueger zone 5 [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments. Hi, The right place to look at the CRS definitions is the official site "epsg.org". So not "epsg.io" nor "spatialreference.org" which have been created because especially in the past the epsg.org site was very unfriendly to use. The link for the CRS is https://epsg.org/crs_31469/DHDN-3-degree-Gauss-Kruger-zone-5.html and the extent is defined as "Germany - former West Germany onshore east of 13°30'E - state of Bayern." The link to the extent is https://epsg.org/extent_1627/Germany-West-Germany-east-of-13-5-E.html In decimal degrees the limits are S:48.51 , N:48.98, E:13.5, W:13.84 Geoserver seems to have correct extent values. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Watermeyer, Andreas Lähetetty: tiistai 25. huhtikuuta 2023 10.10 Vastaanottaja: geoserver-devel@lists.sourceforge.net Aihe: [Geoserver-devel] CRS bbox for EPSG:3149 / Gauss-Krueger zone 5 Hi community, I don't understand the bbox GeoServer is using for EPSG:31469. In the list of crs in the demo section of the admin ui GeoServer shows the following values as bounds: 48°58'48,0"N, 13°30'00,0"E - 48°30'36,0"N, 13°50'24,0"E According to https://spatialreference.org/ref/epsg/31469/ the bounds are: WGS84 Bounds: 13.5000, 47.2700, 16.5000, 55.0600 * Why are the bounds in GeoServer so much smaller? * Can I somehow reconfigure the bounds? I read about epsg_ovverride.properties, but AFAICS the bounds are not part of the WKT. Thanks in advance! Best regards, Andreas ___ 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] CRS bbox for EPSG:3149 / Gauss-Krueger zone 5
Hi Jukka, thanks for your response! I know that site - I find it also confusing. For what I can say the bbox mentioned there is too small, too. >From that site: Name: Germany - West Germany - east of 13.5°E Description: Germany - former West Germany onshore east of 13°30'E - state of Bayern. Extends: 13.5 ° - 13.84 °, 48.98 ° - 48.51 ° Conversion: 3-degree Gauss-Kruger zone 5 Remarks: Zone width 3 degrees. Also used offshore by State Geological Surveys So, to me is unclear: * why do "conversion" and "remarks" say it is a 3 degree width but the extend only cover 13.5 ° - 13.84 ° * what means "conversion" ? Thank you and best regards, Andreas -Ursprüngliche Nachricht- Von: Rahkonen Jukka Gesendet: Dienstag, 25. April 2023 09:50 An: Watermeyer, Andreas ; geoserver-devel@lists.sourceforge.net Betreff: Re: CRS bbox for EPSG:3149 / Gauss-Krueger zone 5 [Externe E-Mail] Vorsicht beim Öffnen von Links und Anhängen. / Be careful when opening links and attachments. Hi, The right place to look at the CRS definitions is the official site "epsg.org". So not "epsg.io" nor "spatialreference.org" which have been created because especially in the past the epsg.org site was very unfriendly to use. The link for the CRS is https://epsg.org/crs_31469/DHDN-3-degree-Gauss-Kruger-zone-5.html and the extent is defined as "Germany - former West Germany onshore east of 13°30'E - state of Bayern." The link to the extent is https://epsg.org/extent_1627/Germany-West-Germany-east-of-13-5-E.html In decimal degrees the limits are S:48.51 , N:48.98, E:13.5, W:13.84 Geoserver seems to have correct extent values. -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: Watermeyer, Andreas Lähetetty: tiistai 25. huhtikuuta 2023 10.10 Vastaanottaja: geoserver-devel@lists.sourceforge.net Aihe: [Geoserver-devel] CRS bbox for EPSG:3149 / Gauss-Krueger zone 5 Hi community, I don't understand the bbox GeoServer is using for EPSG:31469. In the list of crs in the demo section of the admin ui GeoServer shows the following values as bounds: 48°58'48,0"N, 13°30'00,0"E - 48°30'36,0"N, 13°50'24,0"E According to https://spatialreference.org/ref/epsg/31469/ the bounds are: WGS84 Bounds: 13.5000, 47.2700, 16.5000, 55.0600 * Why are the bounds in GeoServer so much smaller? * Can I somehow reconfigure the bounds? I read about epsg_ovverride.properties, but AFAICS the bounds are not part of the WKT. Thanks in advance! Best regards, Andreas ___ 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] CRS bbox for EPSG:3149 / Gauss-Krueger zone 5
Hi community, I don't understand the bbox GeoServer is using for EPSG:31469. In the list of crs in the demo section of the admin ui GeoServer shows the following values as bounds: 48°58'48,0"N, 13°30'00,0"E - 48°30'36,0"N, 13°50'24,0"E According to https://spatialreference.org/ref/epsg/31469/ the bounds are: WGS84 Bounds: 13.5000, 47.2700, 16.5000, 55.0600 * Why are the bounds in GeoServer so much smaller? * Can I somehow reconfigure the bounds? I read about epsg_ovverride.properties, but AFAICS the bounds are not part of the WKT. Thanks in advance! Best regards, Andreas ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] RFC on GetFeatureInfo: Support grids providing features instead of image pixel data
Dear GeoServer-Wizards, we have implemented a custom GeoTools GridFormat/GridCoverageReader (..) to publish raster data from a proprietary GIS system via GeoServer as WMS. Everthing works fine apart from GetFeatureInfo: GeoServer by default returns the pixel data of the raster. Instead we would like to provide the relevant SimpleFeatures we can query from the backend. In the past we patched RasterLayerIdentifier to achieve that. But patching gets annoying over time. I am now looking for a better solution. 1) AFAICS this is not directly supported? 2) As a solution I had the following idea: * Implement another LayerIdentifyer, lets say "FeatureAwareRasterLayerIdentifier". * Based on the capabilities of the AbstractGridFormat GeoServer could decide which LayerIdentifier to use: * AbstractGridFormat.accepts(Object): boolean could be used with a parameter like "evalute-object/simple-feature" to evaluate its capabilities * "FeatureAwareRasterLayerIdentifier" would then call GridCoverage2DReader.read(GeneralParameter[]): GridCoverage2D and on the result it could call GridCoverage2D.evaluate(DirectPosition): Object. The resulting Object would be List. No existing code would break. For others to benefit from the functionallity a corresponding GridFormat implementation is required. I don't have running code now, it is just an idea. I hope it is halfway clear. Could this be a way to go? Could you imagine to accept such a contribution? Best regards and many thanks for your comments in advance, Andreas ITS Digital Solutions GmbH Dillenburger Str. 77 D-51105 Köln Tel.: +49 (0)221 820 07 00 Fax : +49 (0)221 820 07 22 Mail: i...@its-digital.de Sitz der Gesellschaft: Dortmund Amtsgericht Dortmund, HRB 28563 Geschäftsführer: Gunnar Haack, Ludger Schulte, Heinrich Toben, Raimund Schipp, Ralf Petersilka Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Extending control flow by config per layer
Hi Andrea, thanks for your quick response! See my answers below inline. Best regards, Andreas Von: andrea.a...@gmail.com <andrea.a...@gmail.com> im Auftrag von Andrea Aime <andrea.a...@geo-solutions.it> Gesendet: Montag, 15. Januar 2018 11:46 An: Watermeyer, Andreas Cc: geoserver-devel@lists.sourceforge.net Betreff: Re: [Geoserver-devel] Extending control flow by config per layer On Mon, Jan 15, 2018 at 11:13 AM, Watermeyer, Andreas <andreas.waterme...@its-digital.de<mailto:andreas.waterme...@its-digital.de>> wrote: Hello list, we would like to use the control flow extension, but we need to configure it per layer, which is currently not supported. We will implement something for our project and we can offer to contribute the code. 1) Is there any interest in such a contribution? > Yes, that seems to be a useful addition, at least in principle. What's the > use case for doing it by layer? Typically I hear of users asking different > rules per user role instead (QoS classes). Also, how do you handle requests with multiple layers? Most strict rule applies? We have two kinds of layers: The first kind is based on Oracle, GeoServer renders the images. The second is just cascading another WMS, GeoServer enforcess access control rules. In our case only the first shall be throttled in order to prevent CPU bottlenecks through rendering. Thats what I understood from several recommendations (your "GeoServer in production" slides, etc). Multiple layers: It would be as in the current implementation: The flow controllers would processed by one by one, ordered by priority. If multiple match, multiple have to be satisfied. I wouldnt skip one controller because of the match of another. I had a look at the code and I have some questions upfront, trying to create a solution which is benefitial for the GeoServer project: 2) I have experience with WMS and WFS only. For WMS it is quite simple to extract the layers from the URL. The GetMap implementation uses a GetMapKvpRequestReader to extract the layers, which is part of gs-wms. This also performs some validations but doesnt provide an API to extract the layers only. I suggest not to use the GetMapKvpRequestReader but simply check the HTTP request param "layers". Is this approach acceptable? Any other recommendations? 3) To determine the affected WFS feature type is not so simple. The information might be contained in an XML document, which is not parsed at that point AFAICS. Duplicate parsing is not a solution. I currently dont see a simple solution. In our project we need to restrict GetMap requests only, so I will concentrate on a solution for WMS GetMap and leave the rest open. Is this acceptable and still of worth for the community? I would log some warnings if somebody configured a limit for a layer using service-request-combination other than WMS-GetMap. > Doing your own parsing is indeed not an option. Check what the monitoring > module is doing, it's already extracting layer lists from the various > protocols, using a dedicated class fetching the info post-parsing. That is interesting. Now I see the operation specific parameter object is already there, so parsing etc has already taken place. The control flow would require the same code as the monitoring extension. What do you think about moving the code to a common module available for both? Which? 4) The configuration is currently as follows: ows.[.[.]]= 4.1) I suggest to extend it to ows.[.[.[.]]]= Actually the ordering is not quite as expected, it would be better to keep it top-down (ows.[.[.[.]]]), but that would be a breaking change in the configuration. > Yeah, it's not exactly great. Thinking out loud, maybe it's time to switch it > to a XML format. Others might chime in with ideas too. 4.2) As values for I'd support an asterisk (*), matching all formats. 4.3) As value for layer I'd support an asterisk, too, for text matching, for example to match a layers of a workspace (tiger:*) Yep, the above is consistent with other usage in GeoServer (e.g., security) 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 AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di proce
[Geoserver-devel] Extending control flow by config per layer
Hello list, we would like to use the control flow extension, but we need to configure it per layer, which is currently not supported. We will implement something for our project and we can offer to contribute the code. 1) Is there any interest in such a contribution? I had a look at the code and I have some questions upfront, trying to create a solution which is benefitial for the GeoServer project: 2) I have experience with WMS and WFS only. For WMS it is quite simple to extract the layers from the URL. The GetMap implementation uses a GetMapKvpRequestReader to extract the layers, which is part of gs-wms. This also performs some validations but doesnt provide an API to extract the layers only. I suggest not to use the GetMapKvpRequestReader but simply check the HTTP request param "layers". Is this approach acceptable? Any other recommendations? 3) To determine the affected WFS feature type is not so simple. The information might be contained in an XML document, which is not parsed at that point AFAICS. Duplicate parsing is not a solution. I currently dont see a simple solution. In our project we need to restrict GetMap requests only, so I will concentrate on a solution for WMS GetMap and leave the rest open. Is this acceptable and still of worth for the community? I would log some warnings if somebody configured a limit for a layer using service-request-combination other than WMS-GetMap. 4) The configuration is currently as follows: ows.[.[.]]= 4.1) I suggest to extend it to ows.[.[.[.]]]= Actually the ordering is not quite as expected, it would be better to keep it top-down (ows.[.[.[.]]]), but that would be a breaking change in the configuration. 4.2) As values for I'd support an asterisk (*), matching all formats. 4.3) As value for layer I'd support an asterisk, too, for text matching, for example to match a layers of a workspace (tiger:*) Any comments are welcome. Best regards, Andreas -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
