rse 98/06/17 05:03:40
Modified: . STATUS
Log:
Some latest news about this heavy problem...
Revision Changes Path
1.431 +15 -7 apache-1.3/STATUS
Index: STATUS
===================================================================
RCS file: /export/home/cvs/apache-1.3/STATUS,v
retrieving revision 1.430
retrieving revision 1.431
diff -u -r1.430 -r1.431
--- STATUS 1998/06/16 03:59:01 1.430
+++ STATUS 1998/06/17 12:03:39 1.431
@@ -13,13 +13,21 @@
RELEASE SHOWSTOPPERS:
* Ralf: mod_so doesn't correctly initialise modules. For instance
- the handlers of mod_perl are not initialised. An ap_init_modules()
could
- be done from mod_so but this is too much. IMHO we need an API function
- ap_init_single_module() which does what ap_init_modules() does but only
- for a particular module. Currently at least mod_perl is broken under
the
- DSO situation because of this missing init in mod_so. But perhaps
- there are more modules which have the same problem. This should
- be fixed for 1.3.1!
+ the handlers of mod_perl are not initialised.
+ An ap_init_modules() could be done from mod_so but this is too much.
+
+ I've already debugged this up to ap_invoke_handler() and it correctly
+ sees the handlers from mod_perl ("perl-script") and actually runs them.
+ But under DSO situation it returns DECLINED while under non-DSO
+ situation it runs fine. Sure, its mod_perl's fault because its mod_perl
+ code which returns DECLINED. But it definitely seems to be caused by a
+ missing init in mod_so under DSO situation. I've already asked Doug for
+ hints but he still has no clue.
+
+ Currently at least mod_perl is broken under the DSO situation because
of
+ this missing init in mod_so. But perhaps there are more modules which
+ have the same problem. This should be fixed for 1.3.1 or at least found
+ out why it is happening!
WIN32 1.3 RELEASE SHOWSTOPPERS:
