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 <jdeol...@gmail.com> 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 <gabriel.rol...@gmail.com> > 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 <jdeol...@gmail.com> >> 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: <layerName>" >>> >>> 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
