If you are talking about status codes, I'm -1. That should be passed through from Tomcat without change.
If Tomcat hangs up, then there is almost no useful information available, so there isn't much to report. If the client hangs up, then like jk1, we should just stop processing and return OK to Apache. I'm probably just misunderstanding what situations you are trying to handle here, so if you can be a little bit more verbose, I'll probably change my vote. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 12, 2001 9:12 PM Subject: Jk2: error handling and method signatures > Hi, > > One more change I want to do in jk2 is better error handling. Most of us > spent enough time with java that using an 'int' is very uncomfortable :-) > > My proposal is to use jk_env in the same 'style' as in JNI programming. > Each jk method will have as the first parameter a jk_env *env ( that > requires just a bit of regexp ). > > Before the first call to a jk method, we'll use a jk_getEnv, which will > return a (pooled) jk_env. > > env will have "errorString", "errorFile", eventually a method throw() that > will set the things. This would allow mod_jk to report the exact problem. > > Exactly the same method is used in jni - a jni worker could actually > wrap JNIEnv. > > I also believe the code will be easier to read this way. > > This is obviously not 'required' - we can live without it. Please let me > know what you think - I implement it pretty quickly. > > Costin > > > -- > 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]>
