On Thu, Dec 20, 2001 at 03:22:33PM -0500, Greg Ames wrote:
> ...are more painful to deal with than you might think, if the user is
> allowed to code them in any order.
>
> I'd like the comparisons between MaxClients and ServerLimit and the
> equivalent thread directives to be coding order insensitive. So I
> created a post-config hook to do the comparing & adjusting. The code
> was very simple, but the log messages went to the error log file twice,
> rather than to the console once which is what people are accustomed to
> for config errors.
>
> worker already has the same situation with MaxClients and
> ThreadsPerChild. It has a clever but kind of scary solution: a
> pre-config hook which swaps nodes in the config tree if it doesn't like
> the order. Then the comparisons, adjusting, and logging are done when
> the second directive is parsed.
>
> While I think it's a very cool hack, mucking with the innards of the
> config tree bothers me some. config.c could provide an API to do order
> checking and swapping, but I can't see this as a general solution.
> Think about cases where one directive is in container X and the other
> isn't - yuck!
I agree (and I'm the one who wrote it).
> What if the very first ap_run_post_config hook was moved to before the
> logs files were opened? Then we could have simple logic to compare or
> otherwise process multiple directives. Any error messages would go
> directly to the console. If you wanted them to also go to the error log
> file, that would just happen during the second post-config call; if you
> don't want that, it's easy to avoid.
I was thinking the same thing. My only concern was that something has
already been written that assumes post_config already has the log opened
and stderr redirected. Unless that is a problem or someone else can
come up with another reason not to do this, I'm +1.
Another possibility that would avoid the whole issue altogether would
be to simply add another hook before open_logs. I started doing this
yesterday on the plane:
Index: server/main.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/main.c,v
retrieving revision 1.111
diff -u -u -r1.111 main.c
--- server/main.c 2001/12/18 20:26:15 1.111
+++ server/main.c 2001/12/20 20:31:52
@@ -412,6 +412,10 @@
destroy_and_exit_process(process, 0);
}
apr_pool_clear(plog);
+ if ( ap_run_validate_config(pconf, plog, ptemp, server_conf) != OK) {
+ ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR| APLOG_NOERRNO, 0, NULL,
+"Unable to validate the config\n");
+ destroy_and_exit_process(process, 1);
+ }
if ( ap_run_open_logs(pconf, plog, ptemp, server_conf) != OK) {
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR| APLOG_NOERRNO, 0, NULL,
"Unable to open logs\n");
destroy_and_exit_process(process, 1);
Index: include/http_config.h
===================================================================
RCS file: /home/cvs/httpd-2.0/include/http_config.h,v
retrieving revision 1.92
diff -u -u -r1.92 http_config.h
--- include/http_config.h 2001/11/24 00:08:29 1.92
+++ include/http_config.h 2001/12/20 20:31:55
@@ -974,6 +974,18 @@
AP_DECLARE_HOOK(void,pre_config,(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t
*ptemp))
/**
+ * Run the validate_config function for each module. This function should
+ * validate the config parameters accepted by the module, and return
+ * OK or non-OK to signify success.
+ * @param pconf The config pool
+ * @param plog The logging streams pool
+ * @param ptemp The temporary pool
+ * @param s The list of server_recs
+ * @return OK or DECLINED on success anything else is a error
+ */
+AP_DECLARE_HOOK(int,validate_config,(apr_pool_t *pconf,apr_pool_t *plog,apr_pool_t
+*ptemp,server_rec *s))
+
+/**
* Run the post_config function for each module
* @param pconf The config pool
* @param plog The logging streams pool
-aaron
