On Fri, Apr 8, 2016 at 6:25 PM, Eric Covener <cove...@gmail.com> wrote:
> On Fri, Apr 8, 2016 at 6:32 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > It was working, in the sense that it had the intended effect (the > [un]define > > took effect) in the broader global context. > > > > This is a breaking change to some potentially existing configs, however > > misguided they are, which is the sort of thing we've avoided in the > released > > branch. > > > > Could we log an error rather than preventing startup? One issue is that > > these directives are encountered prior to opening the error log file. > One > > possible fix would be to have a second directive handler with the sole > > purpose of emitting errors, running at the normal processing scope, and > > not within exec_on_read. > > This seems to work inside a directive handler on unix and ends up in > the console: > > ap_log_perror(APLOG_MARK, APLOG_STARTUP, 0, cmd->pool > While it works on windows, this error is logged to the event log (while on unix for a service, it should wind up in the syslog). Not sure if that is entirely simple for the user to observe.
