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

Reply via email to