Quoting [EMAIL PROTECTED]: > It's jk_translate who decides if a request is to be handled by > jk ( by mapping it to a uriEnv ). > > You can add a test for r->handler==DIR_MAGIC_TYPE, but don't assume > any uriEnv is set.
OK, I did that in jk2_handler(), which now seems like the wrong place to do it, and I also tried to make sure uriEnv is populated, but I don't think I'm picking it from the correct spot (if it makes any difference at all). I did: ------------------------- ap_get_module_config(r->server->module_config, &jk2_module); ------------------------- where I maybe should have done: ------------------------- ap_get_module_config(r->per_dir_config, &jk2_module); ------------------------- Honestly, I don't understand neither mod_jk2 (surprise :-) nor Apache2 enough to make a decision about that. So, I'll leave this up to you guys to correctly identify. However, the most confusing part of this whole business is this (I'll ask this in terms of mod_jk, but it should be similar for mod_jk2): If jk_translate() is the one mapping requests and also in charge of setting the value of r->handler (which will later on be used by jk_handler() to recognise that this as something for Tomcat and eventually serve the request), that would mean that it must have recognised the requested URI that had r->handler==DIR_MAGIC_TYPE as the one that should be mapped too. I don't see anything in the code that would discriminate on the basis of r->handler, except for manual mappings, which does not include DIR_MAGIC_TYPE. So, the unsolved questions for me are: 1. What is it then that jk_handler() does that makes it actually serve the request when DIR_MAGIC_TYPE is included in the test? It must be that its mapping is 'better' than mapping of jk_translate()... 2. Or is it that jk_translate() never even gets involved during that request and therefore never has the chance to do the mapping? Bojan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
