[BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

2002-07-18 Thread Bojan Smojver

I've looked through Mark's excellent analysis of the problem
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10789) and I also played with
changing the hook order for mod_jk 1.2.0. Are you sure this actually fixes the
thing?

My experience from 1.2.0 is similar to Mark's with 2.x - the handler never gets
called because the r-handler is DIR_MAGIC_TYPE, not JK_HANDLER. So, I think
Mark's code would be the real fix for both - giving Apache a hint that the
handler is JK_HANDLER.

My original 'fix' (more like a kludge) for 1.2.0 doesn't do that. It waits for
the next round, accepts the DIR_MAGIC_TYPE call, where r-uri isn't the correct
file (i.e. it is not /some/path/index.jsp), but rather a directory
(/some/path/), which then causes havoc down the line in getServletPath(). Tomcat
3.3.x is smart and it corrects that for JSP's. I'm not sure if TC 4.x does that
at all (I have seen at least one other report related to bug 9913 with TC 4.x
where my 'fix' didn't actually fix the problem - some fix :-).

Mladen, what's your take on all this? Do you have a setup handy to verify that
the changing of hook ordering fixed the problem in mod_jk2?

Mark, does the fix in mod_jk2 work in your environment?

Bojan

PS. Sorry guys, this one is *really* bugging me...

Quoting [EMAIL PROTECTED]:

 mturk   2002/07/18 08:15:00
 
   Modified:jk/native2/server/apache2 mod_jk2.c
   Log:
   Fix the bug 10789 caused by hook order.
   
   Revision  ChangesPath
   1.42  +3 -3 
 jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
   
   Index: mod_jk2.c
   ===
   RCS file:
 /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
   retrieving revision 1.41
   retrieving revision 1.42
   diff -u -r1.41 -r1.42
   --- mod_jk2.c   17 Jul 2002 22:43:58 -  1.41
   +++ mod_jk2.c   18 Jul 2002 15:15:00 -  1.42
   @@ -724,8 +724,8 @@
ap_hook_handler(jk2_handler, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_post_config(jk2_post_config,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_child_init(jk2_child_init,NULL,NULL,APR_HOOK_MIDDLE);
   -ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_FIRST);
   -ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL,
 APR_HOOK_MIDDLE);
   +   
 ap_hook_translate_name(jk2_translate,NULL,NULL,APR_HOOK_MIDDLE);
   +ap_hook_map_to_storage(jk2_map_to_storage, NULL, NULL,
 APR_HOOK_FIRST);
}

module AP_MODULE_DECLARE_DATA jk2_module =
   
   
   
 
 --
 To unsubscribe, e-mail:  
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

2002-07-18 Thread Mark Miesfeld

On Fri, 19 Jul 2002 13:57:22 +1000 (EST), Bojan Smojver wrote:

: My experience from 1.2.0 is similar to Mark's with 2.x - the handler never gets
: called because the r-handler is DIR_MAGIC_TYPE, not JK_HANDLER. So, I think
: Mark's code would be the real fix for both - giving Apache a hint that the
: handler is JK_HANDLER.
:
:  ...
:
: Mladen, what's your take on all this? Do you have a setup handy to verify that
: the changing of hook ordering fixed the problem in mod_jk2?
:
: Mark, does the fix in mod_jk2 work in your environment?

I was just getting ready to post something saying the fix seems to break
mod_jk2 altogether for me.

For one thing, I think, if jk2_map_to_storage is invoked before
jk2_translate then mod_jk2 is going to return DECLINED all the time.
Which is what I am seeing.  Nothing gets sent over to tomcat.

For example:

jk2_map_to_storage( ) ENTER
  Unparsed uri:   /tomcat/examples
  request_rec:009D79A8
  Return DECLINED
jk2_map_to_storage( ) ENTER
  Unparsed uri:   /tomcat/examples/
  request_rec:009D79A8
  Return DECLINED
jk2_map_to_storage( ) ENTER
  Unparsed uri:   /tomcat/examples/index.html
  request_rec:009D59A0
  Return DECLINED
jk2_map_to_storage( ) ENTER
  Unparsed uri:   /tomcat/examples/index.jsp
  request_rec:009D59A0
  Return DECLINED
jk2_handler( )ENTER
  Unparsed uri:   /tomcat/examples/
  request_rec:009D79A8
  uriEnv: 
  Return DECLINED

In jk2_map_to_storage the start of the code is:

jk_uriEnv_t *uriEnv=ap_get_module_config( r-request_config, jk2_module );

if( uriEnv != NULL ) {

but the only calls to

  ap_set_module_config( r-request_config, jk2_module, uriEnv );

are in jk2_translate.

So, it seems to me that jk2_translate needs to be invoked before
jk2_map_to_storage.  Which is what I thought the original order was.
But I have to confess I really do not understand APR_HOOK_MIDDLE,
APR_HOOK_FIRST, etc..

Anyhow, the bottom line is that on my machine doing a clean and then
rebuilding tomcat and mod_jk2 using the latest jakarta-tomcat-connectors
from cvs, leaves me with mod_jk2 not sending anything on to tomcat.


--
Mark Miesfeld
[EMAIL PROTECTED]


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [BUGS: 9913, 10789] Re: cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

2002-07-18 Thread Bojan Smojver

Quoting Mark Miesfeld [EMAIL PROTECTED]:

 I was just getting ready to post something saying the fix seems to
 break mod_jk2 altogether for me.

Interesting. I haven't actually checked explicit calls to pages with reversed
order and mod_jk 1.2.0, so I don't really know if that breaks it or not. Will
test tonight (Sydney time).

 For one thing, I think, if jk2_map_to_storage is invoked before
 jk2_translate then mod_jk2 is going to return DECLINED all the time.
 Which is what I am seeing.  Nothing gets sent over to tomcat.
 
 For example:
 
 jk2_map_to_storage( ) ENTER
   Unparsed uri:   /tomcat/examples
   request_rec:009D79A8
   Return DECLINED
 jk2_map_to_storage( ) ENTER
   Unparsed uri:   /tomcat/examples/
   request_rec:009D79A8
   Return DECLINED
 jk2_map_to_storage( ) ENTER
   Unparsed uri:   /tomcat/examples/index.html
   request_rec:009D59A0
   Return DECLINED
 jk2_map_to_storage( ) ENTER
   Unparsed uri:   /tomcat/examples/index.jsp
   request_rec:009D59A0
   Return DECLINED
 jk2_handler( )ENTER
   Unparsed uri:   /tomcat/examples/
   request_rec:009D79A8
   uriEnv: 
   Return DECLINED
 
 In jk2_map_to_storage the start of the code is:
 
 jk_uriEnv_t *uriEnv=ap_get_module_config( r-request_config,
 jk2_module );
 
 if( uriEnv != NULL ) {
 
 but the only calls to
 
   ap_set_module_config( r-request_config, jk2_module, uriEnv );
 
 are in jk2_translate.
 
 So, it seems to me that jk2_translate needs to be invoked before
 jk2_map_to_storage.  Which is what I thought the original order was.
 But I have to confess I really do not understand APR_HOOK_MIDDLE,
 APR_HOOK_FIRST, etc.

I don't really understand Apache all that well, but the API documentation talks
about 'Controlling hook calling order'. From 'Apache Hook Functions' document:
...all modules using HOOK_FIRST will run before the HOOK_MIDDLE which are
before HOOK_LAST. If the order is unimportant, HOOK_MIDDLE is recommended.

 Anyhow, the bottom line is that on my machine doing a clean and then
 rebuilding tomcat and mod_jk2 using the latest
 jakarta-tomcat-connectors
 from cvs, leaves me with mod_jk2 not sending anything on to tomcat.

OK. I'll try your solution with mod_jk 1.2.0 and mod_jk2 people might do the
same. I don't really like my fix in 1.2.0 because it's just a cheap hack and it
doesn't address the root cause of the problem

The reason why it didn't work in mod_jk2 is the fact that the test was wrong. It
should have been:

---
if((uriEnv==NULL || strcmp(r-handler,JK_HANDLER)) 
   strcmp(r-handler,DIR_MAGIC_TYPE)))
return DECLINED;
---

But even that probably wouldn't work with TC 4.x because getServletPath() would
start returning strange things. I think your approach is much better.

Bojan

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]