Sorry I have been heads down working on this and have not provided an update for some days.
The GeoTools and GeoWebCache upgrade has gone smoothly (just a lot of work).
The GeoServer upgrade also went well, especially using the log4j 1.2 api for configuration.
Where I have run into trouble is switching over to using Log4j 2 api for configuration; despite the widely publicized vulnerabilities the configuration is far more locked down and not open to being updated while the application is running…
There are three things we wish to post-process:
RELINQUISH_LOG4J_CONTROL system/context/env value
Overriding the log output file location using GT2_LOGGING_REDIRECTION system/context/env value or from settings
Surpassing all console loggers from settings
Surpassing all file loggers, flag used by test cases
There are examples of how to safely add appenders to a configuration, by hijacking the configuration factory. But it has been quite annoying to provide an alternate log output file location as our technique (system/context/env or setting) - is more flexible than the out-of-the-box support log4j has for log file properties.
The above technique is intended to be used to quickly isolate a property making the configuration easier to maintain, support is available to reference ${env: GEOSERVER_LOG_LOCATION} or {sys:GEOSERVER_LOG_LOCATION} or {web: attr. GEOSERVER_LOG_LOCATION} … but not all three at once.
There is also a thread local, ${ctx:GEOSERVER_LOG_LOCATION} which can be combined with something called routing. The point being that it is carefully designed to be declarative and does not take kindly (or provide a mechanics) for a configuration to be post processed; and only limited ability to add appenders, and no ability to edit properties.
Grr…
So I have made progress by taking one of the suggesting, making a custom GeoServerXmlConfiguration (registered by a GeoServerXmlConfigurationFactory), as the only safe way to post-process content during load.
And then found a protected method available for just-in-time creativity:
@Override protected void preConfigure(Node node) {
if( !node.isRoot() && node.getName().equals(“Property”)){
if( node.getAttributes().containsKey(“name”) &&
node.getAttributes().get(“name”).equals(“GEOSERVER_LOG_LOCATION”)) {
// override value with current GEOSERVER_LOG_LOCATION
node.setValue(“foo.log”);
}
}
super.preConfigure(node);
}
I think this is the last technical hurdle, next task is figure out how to pass in current value of GEOSERVER_LOG_LOCATION (or make LoggingUtils responsible for this), and pulling this together.
Hi Jody,
silly question maybe, but did you try to reach out to the Log4J2 community and see if there
is a less painful way to do it?
Being able to change the log config without restarts is key to the day to day management of GeoServer.
Otherwise, maybe we can look into Logback (75% kidding here)
Cheers
Andrea
···
Regards,
Andrea Aime
==
GeoServer Professional Services from the experts!
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
I can run an experiment, but logback was also very much configuration up front and under external control attitude (which is not a bad attitude to be honest).
This took a long time to write up, but doing so kind of confirmed for me that I am using the API as they intended. The “Node” data structure is what their builder infrastructure produces (either parsing or direct use of builders). And I am indeed correctly hacking the results of parsing before it is used to create real objects (which do not like to be changed once created).
That said they are missing out on an opportunity to be kind to me, their builders do not provide any ability to update only add.
I got feedback via https://issues.apache.org/jira/browse/LOG4J2-3469 that what I am doing is safe, but not in the spirit of Log4J2 (which is external control focused, preventing a lot of applications from updating).
The offered a slightly prettier way to things, but I still do not like it (my own personal feeling)
The majority of the work has gone into cleaning up our LoggingUtils (and supporting LoggingStartupContextListener and LoggingInitializer) so they do not trip on each other, can update the database directory configs in place, etc…
I am going to complete the work based on their feedback so we have something; but I am close to trying logback.
I would like to issue a release candidate Wednesday, in order to collect feedback from our user community with respect to this change.
I will be away next week, and my next opportunity to make a release candidate will May 2nd.
Global settings page re-ordered with headings matching the user interface
Added references to individual settings for better cross linking
Live examples of the logging profiles.
One interesting discovery was how log4j handles our example where GEOSERVER_LOG_LOCATION is used to supply each node its own log file (while sharing a common data directory).
Where hostName is the system host name in the filename and filePattern above.
I also added some data cleaning to prevent any property substitution being added as part of geoserver log file location being passed in from global settings, and took some care to preserve the extension and various log4j decorations provided by the profile.