Jody here with some notes for the discussion:
Most of the notes here are diverging from the point at hand, and present no novelty. I’m going to use a GeoServer 2.20.0 release I have locally to show
the behavior previous to the one incompatible change pointed out at the beginning of this thread.
- The documentation refers to these as built-in logging configurations. I think it is good that the built-in logging configurations are available for use as an example (rather than just hidden in a jar).
https://docs.geoserver.org/main/en/user/configuration/logging.html
Using 2.20.0, I have removed all the configuration logging files (*.pèroperties), restarted GeoServer, they are all back in the directory.
They have always served as example, never been hidden in a jar file.
- The documentation on customization (above) has an example that starts with copying a built-in configuration and making changes.
The ability to configure a custom profile is not new, I have been creating them for ages. Here is the 2.20.x documentation, showing
how to customize a logging profile using property files:
https://docs.geoserver.org/2.20.x/en/user/configuration/logging.html#custom-logging-profiles
- The blog post has some more details on updating from properties → xml; but also updating about the built-in xml definitions updating each release. Reading the blog post it just has an example using properties and not an xml file.
Communication is good, thank you for doing that. However, not relevant to the point at hand, let me copy and paste the title of this thread:
“Default logging profiles are no longer customizable” .
For reference, I edited the 2.20.x DEFAULT_LOGGING.properties to a date format more similar to a ISO date,
started GeoServer, pattern holds, stop and restart, still there.
As said above, if one wants to recover the built-in tiles, they just have to remove them, and GeoServer 2.20.x would
expand them back from the classpath.
This is the behavior everyone has been used to, for at least the past 15 years.
If you made any customizations to the built-in profiles, you can recover your changes from backup bak file. You can use this backup as a reference when creating a new xml logging profile, or restore this under a different name which does not conflict with the built-in logging profiles.
That has been your own decision, taken without discussing it in a GSIP or mentioning it during mail discussion. This is the real point of this thread.
Change is possible, but it requires public discussion, not single handled bulldozing because you think you know better.
If and when the PSC agrees the direction is good, then we communicate to users that the behavior they were used to, it’s no longer there.
- I do expect these logging configuration to change over time, see bug https://osgeo-org.atlassian.net/browse/GEOS-10701 for an example. As such it is nice to treat these as built-in and managed as part of the software.
I expect to own the files just like any other file in the data directory. I has been like that for as long as I can remember.
It was not your place to make this decision, you are putting yourself above us all, and the rules/customs that govern this community.
To draw a parallel, can you remove the built-in styles? Not really, GeoServer will try to re-create them, because it needs them to work.
Can you edit them? Yes you can, I do it all the time (it’s my own responsibility to keep them semantically in line with their intended usage,
and if not, I’ll pay the price at every new layer configured).
That same goes for the built-in logging profiles, I edit them if I want to get information presented in a different way… e.g., when I’m trying
to debug a concurrency issue at a customer site, I have them add the thread id in the log pattern. That does not change the semantics
of a “DEFAULT_LOGGING”, it’s just giving me better information. Unfortunately most of our customers are still on older versions of
GeoServer and had not noticed the issue until a few days ago.
aside: Initially I tried writing some code that checked if the built-in files had been customized; and only update ones that had not had their checksum change. PR review guidance was to simplify the code. Perhaps reviewers were thinking it was only applying with updating from properties → xml and not an ongoing policy.
Indeed, I could not have expected a PSC member to just go and change the behavior like this. The notion that you’re talking about this
as a precise decision you made, instead of a simple oversight, is even more shocking.
Let me quote a bit of our GSIP process: “Generally you will make a GSIP when you want something major done in GeoServer and need feedback from others. GSIPs are needed for things that will have an impact on other community members, and thus should be talked about.”
Lately you have been waving the “would you like to write a GSIP?” for minor new features, but then
sneak into a large PR a change that does impact on other community members, without discussion.
I believe we need a new GSIP that clarifies, with enumeration and examples, what warrants a GSIP, and
what does not.
···
Regards,
Andrea Aime
==
GeoServer Professional Services from the experts!
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