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).

Jody

On Wed, Apr 6, 2022 at 1:08 AM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:

> 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
>
> On Wed, Apr 6, 2022 at 8:05 AM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> 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.
>>
>> <Configuration name="DEFAULT_LOGGING" status="error" dest="out">
>>     <Properties>
>>         <Property name="GEOSERVER_LOG_LOCATION">logs/geoserver</Property>
>>     </Properties>
>>     ..
>>     <Appenders>
>>         <RollingFile name="geoserverlogfile">
>>             <filename>${GEOSERVER_LOG_LOCATION}.log</filename>
>>             <filePattern>${GEOSERVER_LOG_LOCATION}-%i.log</filePattern>
>>             ...
>>
>> 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.
>> --
>> 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  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
>
-- 
--
Jody Garnett
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to