Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
Sorry for not replying back sooner. I just wanted to look at the latest stuff from CVS ( I used to look at my local CVS repository which is based on TC3.2.1). Couldn't do it sooner - had to to some other things first:) In case you, guys still interested - here it goes:) First I'd like to apologize for not looking at CVS sooner. A lot of things have changed since 3.2.1. I know that you, guys are busy so I'll try to make it short:) This is what I think is still relevant: TC binds to all interfaces. This is insecure (think of shutdown command for example). Also configuration stuff has changed and I haven't found a new way to bind connector to a particular interface. I'm going to try to implement all this in current jakarta-tomcat repository. I'll send another mail with diffs (hopefully today) for your review. On Tue, May 08, 2001 at 10:30:36AM -0700, [EMAIL PROTECTED] wrote: On Tue, 8 May 2001, Andrey Kartashov wrote: What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone has to do it - and closing bugs has bigger priority. If this is an itch for you, and you want to propose something ( and write some code ) - we're listening :-) I think Henri is also considering spliting the distribution in base tomcat, web applications. The connectors are already in a separate RPM. BTW, I like very much the idea of keeping the WARs ( examples, admin, etc) in separate distribution files. It was on the goals list to produce a minimal container, that implements the servlet API and nothing else, and separate the features. That didn't happen so far. Costin Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:) -- oo Andrey oo oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo All mail clients suck. This one just sucks less. -- http://www.mutt.org/ Jeremy Blosser
RE: Tomcat 3.2.2 beta 4
That has fixed that problem. I can now run under Wjview (the M$ VM). I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager.java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] To: Dave Oxley [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Mon, 7 May 2001 08:37:20 -0500 Dave, Thanks, let me know how it works. This is the final show stopper for the Tomcat 3.2.2 release so once I know its been fixed I can start the final release process. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Friday, May 04, 2001 12:54 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Will test it on Saturday. Dave. From: Marc Saegesser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Thu, 3 May 2001 16:39:35 -0500 Dave, A fix for this has been committed. If you can build from source to test this that's great. I've also attached a JAR file with the latest Tomcat build. Just drop the webserver.jar file into your $TOMCAT_HOME/lib directory and start Tomcat. Thanks. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 3:14 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Glad I mentioned it now. I didn't think about the fact it might be a 1.1 thing. We've had so many problems with the M$ VM that I just jumped to conclusions!! The sooner we dump it the better. :) Dave [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 1 May 2001 14:17:13 -0500 Bloody hell. I was just about to launch into a wonderful tirade about why we shouldn't have change Tomcat just to work around some buggy compiler from Microsoft when I realized the real problem isn't what you think it is. The problem isn't the definition of the inner class, but the use of the PrivilegedAction interface. This interface didn't appear until JDK1.2 and my guess is that your using JDK1.1. Tomcat 3.2.x, because it implements the Servlet 1.1 specification must maintain compatibility with JDK1.1 so this is a real Tomcat bug and it will need to be fixed before releasing Tomcat 3.2.2. Glenn, can you take a look at this? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 12:32 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 I posted this before but got no response. The change to SessionUtil.java 1.5.2.2 to 1.5.2.3 (3.2.1-3.2.2b1) has caused the Microsoft Virtual Machine to fall over when running Tomcat. The M$ VM does not like internal classes defined within methods (I think this is the problem
RE: Tomcat 3.2.2 beta 4
Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager.java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager.java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Tomcat 3.2.2 beta 4
Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Tomcat 3.2.2 beta 4
Just tried it and yes: TC3.2.2b4 with AJP12 does work. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 8 May 2001 08:44:03 -0500 Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
On Mon, May 07, 2001 at 11:49:25PM +0200, GOMEZ Henri wrote: Should it become default? I hope the answer is yes:) It also has another value: inet is not a well-known parameter. Having it in default server.xml along with a little comment about what it does may compensate for the lack of proper documentation:) +1 for the addition in server.xml (Marc, Larry ?) Thanks! I don't really understand why Ajp protocol should handle shutdown command at all. I agree that there may be a need for some kind of servlet that handles this operation but WHY THROUGH Ajp protocol??? Adding shutdown in ajp14 will help a web admin to build a control deck to shutdown from ONE POINT some or all of its Tomcat. Correct me if I'm wrong, but it's possible to do the same thing with admin servlet. Besides, it seems to me that most of the time sys admin wants not to shutdown servers permanently but rather update class files or JSPs or reconfigure them and then restart. I think that having admin servlet that supports all (or some of) this things will ease this task a lot. Also it'll make Ajp protocol a tiny bit simpler which is always a good thing Here is one possible use case I've come up with: Sys admin has a script that executes rsync to update all the load-balanced TC machines. He than executes another script that sends HTTP restart command to all the TC's. Restart can be accomplished as following: In JVM: System.exit(EXIT_RESTART); // EXIT_RESTART !=0 :) In tomcat.sh: loop while exit code == EXIT_RESTART; Some people (including myself) like doing configuration manually in [skpd] I'm like you and do by hand all my configuration, and set my JkMount in VirtualHost. But many starting users will like the autoconf features. Note that JkMount could still be used and JkAutoMount is then mandatory... Don't get me wrong:) I'm not against JkAutoMount - it's cool. What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:) -- oo Andrey oo
Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
On Tue, 8 May 2001, Andrey Kartashov wrote: What I'm trying to say is: To address this group of people I'd suggest splitting distribution into pure java Tomcat part + extensions. This way only NECESSARY files will make their way to conf directory. If someone is (for example) interested in running stand-alone TC - he only downloads pure java part. If he needs to hook it into some Web server like Apache or IIS - he downloads apache extensions or IIS extensions, etc. +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone has to do it - and closing bugs has bigger priority. If this is an itch for you, and you want to propose something ( and write some code ) - we're listening :-) I think Henri is also considering spliting the distribution in base tomcat, web applications. The connectors are already in a separate RPM. BTW, I like very much the idea of keeping the WARs ( examples, admin, etc) in separate distribution files. It was on the goals list to produce a minimal container, that implements the servlet API and nothing else, and separate the features. That didn't happen so far. Costin Some people would prefer to use some UI tool to [skpd] Some Admin Servlet could do the job My point exactly:) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. Do you want me to send it again? 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) Done by the official Tomcat RPM which modify tomcat.sh to feed /var/log/tomcat.log Not everyone uses Linux:) Not everyone uses RPM:) I use linux for developiment (but I prefer getting TC as *.tgz), our production systems are running Solaris. I'd still suggest to modify tomcat.sh (don't make this fix RPM-only). There is another cross-platform way of doing the same: System.setOut(errorLogStream); System.setErr(errorLogStream); 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Please. I realize I must'nt be too stupid since we have done many common things :) I would suggest it if it wasn't:))) I'm not proud of it:) It's a hack and I know about it's problems and limitations. That being said - here is what it does: Problem: We are doing wireless ad serving. One of the business rules says that we should support static URL to ad server. Ad server serves multiple ads - hence we need to remember what we've served to whom. It can't be part of the URL (it's static) and it can't be cookie (not all the wireless browsers have it). Solution: We are trying to use device's Global Id (part of the request on most of the devices) as SessionId. The TC java code has been modified accordingly and LB code has been modified to route based on Global Id ( session stickiness ). This solution doesn't address fail over issue properly. A better one would be to have persistent sessions (keep them in Data Base or something ...) but it would cost more. We've made similar modifications to JServ and it's been up for some time. Recently we decided to switch to TC because it supports newer API and is being developed/supported. I reimplemented modifications in TC as well although it hasn't been tested yet. As I said - it's not an elegant solution and If the requirement to have this feature turns out to be not important - we'll get rid of this hack:) Sorry for the long E-Mail:) Hope you've read it:) I read all of it. Hope to read you soon. I'm glad you did:)
RE: Tomcat 3.2.2 beta 4
Spent all day investigating this, and I can't track down the problem. I've written an example class that does servlet to serlvet POST's but I can't make it error with the same problem. I think there must be something more complicated going on. I don't think this should hold up the release of TC3.2.2(if it was) as it is not a new bug introduced since TC3.2.1. I will continue to investigate. Dave [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 15:27:04 +0100 Just tried it and yes: TC3.2.2b4 with AJP12 does work. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 8 May 2001 08:44:03 -0500 Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Tomcat 3.2.2 beta 4
Dave, Thanks for looking at this. If you do come up with a small example that demonstrates the problem let me know. -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 2:16 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Spent all day investigating this, and I can't track down the problem. I've written an example class that does servlet to serlvet POST's but I can't make it error with the same problem. I think there must be something more complicated going on. I don't think this should hold up the release of TC3.2.2(if it was) as it is not a new bug introduced since TC3.2.1. I will continue to investigate. Dave [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 15:27:04 +0100 Just tried it and yes: TC3.2.2b4 with AJP12 does work. Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 8 May 2001 08:44:03 -0500 Dave, Does it work OK with 3.2.2b4 and AJP12? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 08, 2001 7:15 AM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Some further info on this problem. It works fine with TC3.2.1 with AJP12. TC3.2.1 goes into an infinite loop using 100% processor with AJP13. TC3.2.2b4 gives the stack trace with AJP13 but does not infinite loop like TC3.2.1. I have tried with Apache 1.3.19, but it made no difference. I have tried this with Java 1.3.0_01 and 1.3.0_02 with the same results. I am running Windows 2000. I will write a test servlet a bit later on. Dave. [EMAIL PROTECTED] From: Dave Oxley [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Tue, 08 May 2001 12:07:44 +0100 I have just found another problem though. This is not a new problem with 3.2.2. We have just started using the O'Reily HttpMessage code to send a Post message to a servlet from another servlet (in the same virtual machine). The Stream within the POST contains a Vector of Serializable objects. The POST works as expected, no problems, but when shutting down Tomcat we get the following stack trace and the process never finishes. This is using TC3.2.2b4 with Apache 1.3.17 (I will try 1.3.19). java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleError(ContextManager. java:1160) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:800) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) 2001-03-08 11:17:32 - Ctx( ): 404 R( /spweb/servlet/StaffPlannerServlet) null 2001-03-08 11:17:32 - Ctx( ): Exception in: R( /spweb/servlet/StaffPlannerServlet) - java.lang.NullPointerException at org.apache.tomcat.core.ContextManager.handleStatus(ContextManager .java:1058) at org.apache.tomcat.core.ContextManager.internalService(ContextMana ger.java:775) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.proces sConnection(Ajp13ConnectionHandler.java:160) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool. java:501) at java.lang.Thread.run(Thread.java:484) I will write a little sample program if you think it is worthwhile and post it to the group. Dave. [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Tomcat 3.2.2 beta 4
Could you try with the mod_jk from TC 3.3 cvs ? Could you also send a small servlet for test purpose ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: Tomcat 3.2.2 beta 4
I will try with that mod_jk and will send the test servlet as soon as I can write a simple one that breaks. :) Dave [EMAIL PROTECTED] From: GOMEZ Henri [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 Date: Wed, 9 May 2001 00:21:30 +0200 Could you try with the mod_jk from TC 3.3 cvs ? Could you also send a small servlet for test purpose ? - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: Tomcat 3.2.2 beta 4 (insecure default settings)
On Mon, May 07, 2001 at 02:11:35PM +0200, GOMEZ Henri wrote: You're right. TC still use ajp12 at its default connector so it listen all interface (which I agree could rise problem). I'm using in my prod systems, ajp13 to connect webservers and ajp12 only for the shutdown purpose (and listen only on localhost) Here is the same test but with slightly modified server.xml: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/ Parameter name=port value=8007/ Parameter name=inet value=127.0.0.1/ /Connector Thanks to mention this one. The inet is not a well know and used param. Please note that port 8007 is bound to 127.0.0.1 interface _ONLY_. The secure way. Should it become default? I hope the answer is yes:) It also has another value: inet is not a well-known parameter. Having it in default server.xml along with a little comment about what it does may compensate for the lack of proper documentation:) I understand your valid requirement, but why not just developp a servlet in admin which use ajp12 to send (to localhost), the ajp12 shutdown command. Hope this helps :) Yes, and I hope you'll take a look at the ajp14 proposal... I did. I don't really understand why Ajp protocol should handle shutdown command at all. I agree that there may be a need for some kind of servlet that handles this operation but WHY THROUGH Ajp protocol??? It almost sounds like merging two things that serve totally different purpose together. What if you want to add more commands in the future? Would you really want to add these commands into ALL versions of protocol? And how do you handle these commands if you don't? IMHO there are few related but different things one wants to do with TC: 1)Serve requests - handled by Ajp protocol. 2)Configureadministrate - this one is a bit more complex. Some people (including myself) like doing configuration manually in command line interface. Hence there needs to be well defined set of config files and scripts one needs to care about. One of my personal challenges while setting up TC for the first time was to find out what config files are actually necessary. There is whole bunch of files in config directory for ALL the possible platforms/servers, etc. Some people would prefer to use some UI tool to configure the server and issue commands - here is your idea of extending functionality of admin application, add shutdown/restart commands to it as well as may be some other options like configuring connectors, including configuration of ports, interfaces, etc. There may even be some applet for monitoring the log files (like in Sun's JavaWebServer). I think good example is configuration as it is done in Enhydra. This kind of tool doesn't need any middle man in the form of Ajp or any other protocol. It can have hooks directly into server API. The advantage of this is that Ajp protocols remain plugguble unlike Ajp12 that you need to have to issue simple shutdown command and configuration may evolve without any weird dependencies on any particular protocol. Some people MIGHT want to set up distributed environment (read load balancing here) where the same application is physically distributed across multiple machines but configuration MUST be changed synchronously. This may be handled just by some *NIX scripts, etc but in this case having some administration protocol might be usable to build centralized configuration where all the changes are made in one place and communicated to all the balanced servers using some protocol. There are lots of complicated issues here but this is the place where IMHO some protocol might be NECESSERY. And even than I wouldn't add this features into any Ajp?? protocols. I'd much rather define another one that again may evolve differently from Ajp protocols but might use Ajp protocol as a transport layer. Here is the list of modifications that I've done to TC so far: 1) changed defaults to bind to 127.0.0.1 interface in server.xml. 2) changed shutdown code to make it work correctly if inet parameter is used. 3) modified mod_jk logger function to print timestamps in Apache Web server style. 4) modified tomcat.sh file in bin to redirect stdoutstderr to a log file (people complained about not seeing System.out.println() stuff) 5) modified default load balancing behavior to make use of wireless device's global id (I'm not giving details on this one because it's specific to what we are doing and probably useless for others. But I'm not hiding it:) I can describe it if anyone is interested). Sorry for the long E-Mail:) Hope you've read it:) -- oo Andrey oo
RE: Tomcat 3.2.2 beta 4 - AJP14 continuation
Should it become default? I hope the answer is yes:) It also has another value: inet is not a well-known parameter. Having it in default server.xml along with a little comment about what it does may compensate for the lack of proper documentation:) +1 for the addition in server.xml (Marc, Larry ?) I understand your valid requirement, but why not just developp a servlet in admin which use ajp12 to send (to localhost), the ajp12 shutdown command. Hope this helps :) Yes, and I hope you'll take a look at the ajp14 proposal... I did. I don't really understand why Ajp protocol should handle shutdown command at all. I agree that there may be a need for some kind of servlet that handles this operation but WHY THROUGH Ajp protocol??? Adding shutdown in ajp14 will help a web admin to build a control deck to shutdown from ONE POINT some or all of its Tomcat. It almost sounds like merging two things that serve totally different purpose together. What if you want to add more commands in the future? The AJP14 is not closed, it's just a starting point for discussion. Would you really want to add these commands into ALL versions of protocol? And how do you handle these commands if you don't? The AJP15 must handle all commands from AJP14 and will have its owns one. Also you must have notice about the negociation at startup. Some asked to add at start of negociation a string indicating which protocol are supported by web-server. The servlet engine will then use the higher common protocol : ie: web-servlet knows about AJ14/AJP15 but servlet engine only AJP14. The protocol used will be AJP14. web-servlet knows AJ14/AJP15 and servlet engine AJP14/AJP15/AJP16. The discussion will use AJP15. IMHO there are few related but different things one wants to do with TC: 1)Serve requests - handled by Ajp protocol. 2)Configureadministrate - this one is a bit more complex. Some people (including myself) like doing configuration manually in command line interface. Hence there needs to be well defined set of config files and scripts one needs to care about. One of my personal challenges while setting up TC for the first time was to find out what config files are actually necessary. There is whole bunch of files in config directory for ALL the possible platforms/servers, etc. I'm like you and do by hand all my configuration, and set my JkMount in VirtualHost. But many starting users will like the autoconf features. Note that JkMount could still be used and JkAutoMount is then mandatory... Some people would prefer to use some UI tool to configure the server and issue commands - here is your idea of extending functionality of admin application, add shutdown/restart commands to it as well as may be some other options like configuring connectors, including configuration of ports, interfaces, etc. There may even be some applet for monitoring the log files (like in Sun's JavaWebServer). I think good example is configuration as it is done in Enhydra. This kind of tool doesn't need any middle man in the form of Ajp or any other protocol. It can have hooks directly into server API. The advantage of this is that Ajp protocols remain plugguble unlike Ajp12 that you need to have to issue simple shutdown command and configuration may evolve without any weird dependencies on any particular protocol. Some Admin Servlet could do the job Some people MIGHT want to set up distributed environment (read load balancing here) where the same application is physically distributed across multiple machines but configuration MUST be changed synchronously. This may be handled just by some *NIX scripts, etc but in this case having some administration protocol might be usable to build centralized configuration where all the changes are made in one place and communicated to all the balanced servers using some protocol. There are lots of complicated issues here but this is the place where IMHO some protocol might be NECESSERY. And even than I wouldn't add this features into any Ajp?? protocols. I'd much rather define another one that again may evolve differently from Ajp protocols but might use Ajp protocol as a transport layer. AJP13 is still present and supported, but lack some features needed for Servlet API 2.3. My english is bad but AJP14 WILL USE AJP13 as transport layer, there will be new commands added and new cinematic, but AJP14 = AJP13++ Here is the list of modifications that I've done to TC so far: 1) changed defaults to bind to 127.0.0.1 interface in server.xml. Will be changed in server.xml for 3.2/3.3 (Marc/larry are you agree) 2) changed shutdown code to make it work correctly if inet parameter is used. Thanks to (re)send the code to list. 3) modified
Re: Tomcat 3.2.2 beta 4 (insecure default settings)
On Fri, May 04, 2001 at 07:58:17PM -0400, Andrey Kartashov wrote: [skpd] Let's be prudent here. The standard configuration must avoid security hole. Many users will have tomcat in front and we must avoid someone outside shutdown their TC boxes. Let me clarify this:) I don't ask you guys to change default configuration. I ask you to change shutdown code so that if I do change configuration from default to something else - the code'll still work. Also if I'm not mistaken - Tomcat binds to all interfaces by default as I don't see inet= option set to 127.0.0.1 in default server.xml file for Ajp connectors. I'll double check that:) I just did (I mean double checked). I know it's stupid to reply to my own Email but here it goes:) I used fresh untarred binary distribution (no modifications at all) of jakarta-tomcat-3.2.2b4. Here is a fragment of server.xml: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/ Parameter name=port value=8007/ /Connector Here is the output of netstat: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:515 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:80070.0.0.0:* LISTEN tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0104 199.95.200.19:2264.24.41.37:1021ESTABLISHED tcp0 0 199.95.200.19:2264.24.41.37:1022ESTABLISHED tcp0 0 199.95.200.19:2264.24.41.37:1023ESTABLISHED The line containing 8007 is Ajp connector listening on _ALL_ interfaces. Here is the same test but with slightly modified server.xml: Connector className=org.apache.tomcat.service.PoolTcpConnector Parameter name=handler value=org.apache.tomcat.service.connector.Ajp12ConnectionHandler/ Parameter name=port value=8007/ Parameter name=inet value=127.0.0.1/ /Connector Please note the presence of inet parameter here! Here is the output of netstat: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:515 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:8007 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:80800.0.0.0:* LISTEN tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 68 199.95.200.19:2264.24.41.37:1021ESTABLISHED tcp0 0 199.95.200.19:2264.24.41.37:1022ESTABLISHED tcp0 0 199.95.200.19:2264.24.41.37:1023ESTABLISHED Please note that port 8007 is bound to 127.0.0.1 interface _ONLY_. So if security of default settings is of any concern I'd suggest you, guys modify default server.xml file the way described above. Hope this helps :) -- oo Andrey oo oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo All mail clients suck. This one just sucks less. -- http://www.mutt.org/ Jeremy Blosser oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
Re: Tomcat 3.2.2 beta 4 (problem with shutdown code)
On Fri, May 04, 2001 at 09:26:35AM +0200, GOMEZ Henri wrote: Hi, all! I've made a little modification in Tomcat 3.2.1 codebase that I think would be nice to include in TC 3.2.2. Problem: shutdown script always connects to localhost to send shutdown command. It is a problem on a multihomed machine running multiple tomcats where tomcats use same port numbers but bound to different IP adresses using inet= configuration option in server.xml. Hey do you really want someone outside you machine send a shutdown command to your tomcats ? I think it is very common configuration where Ajp connector is bound to something other than 127.0.0.1. Here are couple of examples: It is possible and some times desired to have Apache web server load balance tomcat servers that run on physically different machines; It is possible and some times useful to run mutiple Tomcat instances on the same box that has multiple IP's (this may be good for testing/developement). Warning, Warning here. The localhost is used here for security I strongly disagree with this:) If you configure your Ajp connector to listen to a particular interface someone _CAN_ send you shutdown command regardless of your shutdown code abilities. If you want security - you need to think about your network configuration, not the shutdown code. This is what sys admins are for:) A good example would be a machine that has multiple interfaces with non-routable addresses (a developement machine) Or load balanced machines behind the firewall. I don't mean to enumerate all the possibilities here - this is just a few examples. reasons. I didn't understand why your multihomed machine couldn't listen on localhost ? Thanks to give us more informations, for example did you use multiples JVMs ? Our configuration: We have a developement machine with multiple interfaces running multiple instances of Tomcat. It is behind the firewall. These different interfaces have different internal DNS names and you can't hit them from outside:) There are 2 ways to set up Tomcat here: 1) All Ajp connectors bound to the same 127.0.0.1 but on different ports. 2) Ports are the same but Ajp connectors are bound to different IP's We prefer second case. Why? - It's a matter of tastestyle. The problem is that in this case shutdown code misbehaves as you may guess:) Solution to this is very simple and I had it attached to previous E-Mail. -- oo Andrey oo oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo All mail clients suck. This one just sucks less. -- http://www.mutt.org/ Jeremy Blosser oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
RE: Tomcat 3.2.2 beta 4
Glenn, Costin,
If Glenn is OK with it (since its his security manager stuff thats affected)
then I'm OK with it. The class your talking about are the ones in the
org.apache.tomcat.util.compat package in the TC3.3 source, right?
I'm stuck in an all day meeting today (ouch) and then I've got to move
furniture tonight (ouch again) so I probably won't get to look at this
today. If you guys get the new JDKcompat stuff in I'll review and test
tomorrow.
Thanks for all the help.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
Sent: Wednesday, May 02, 2001 6:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Tomcat 3.2.2 beta 4
Costin,
The code you are referring to in 3.3 makes it easy to abstract out
jdk 1.2 dependencies at build and runtime? If so, I have no
problems with you back porting that into 3.2.
If these classes are generic enough, perhaps they could be put
into the commons.
Regards,
Glenn
[EMAIL PROTECTED] wrote:
On Tue, 1 May 2001, Marc Saegesser wrote:
Costin,
The toLowerCase() patch look OK.
If Glenn can fix the session id stuff easily then I think
thats the best
approach right now.
Adding the jdkcompat package can't hurt - it'll be a minimal change in
SessionUtil plus the addition of 3 classes.
I'll wait for Glenn - it's probably a 15 minutes fix if we use the stuff
from 33.
Costin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 01, 2001 2:58 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Tomcat 3.2.2 beta 4
Marc,
I can quickly backport the jdkcompat package from 3.3 - it would be
cleaner than hacking generateSessionId.
The package is standalone, doesn't depend on any 3.3 feature - and
it's quite simple and effective.
Also, if you could review the following patch that will fix case
sensitive match for host names ( the patch is ported from 3.3 ).
Costin
Index: src/share/org/apache/tomcat/util/PrefixMapper.java
=== RCS
file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMa
pper.java,v
retrieving revision 1.3.2.2 diff -r1.3.2.2 PrefixMapper.java
125a126
host=host.toLowerCase();
165a167
host=host.toLowerCasse();
181a184
host=host.toLowerCase();
201c204
if( host!=null )
---
if( host!=null ) {
202a206,209
if( myMap==null ) {
myMap=(PrefixMapper)vhostMaps.get(
host.toLowerCase() );
}
}
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
RE: Tomcat 3.2.2 beta 4
Done. The code doesn't compile on JDK1.1 ( I can add the excludes for
util.compat, but there are other places in the code - compiling on JDK1.1
is not a major requirement, only the ability to run ).
Costin
On Wed, 2 May 2001, Marc Saegesser wrote:
Glenn, Costin,
If Glenn is OK with it (since its his security manager stuff thats affected)
then I'm OK with it. The class your talking about are the ones in the
org.apache.tomcat.util.compat package in the TC3.3 source, right?
I'm stuck in an all day meeting today (ouch) and then I've got to move
furniture tonight (ouch again) so I probably won't get to look at this
today. If you guys get the new JDKcompat stuff in I'll review and test
tomorrow.
Thanks for all the help.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Glenn Nielsen
Sent: Wednesday, May 02, 2001 6:38 AM
To: [EMAIL PROTECTED]
Subject: Re: Tomcat 3.2.2 beta 4
Costin,
The code you are referring to in 3.3 makes it easy to abstract out
jdk 1.2 dependencies at build and runtime? If so, I have no
problems with you back porting that into 3.2.
If these classes are generic enough, perhaps they could be put
into the commons.
Regards,
Glenn
[EMAIL PROTECTED] wrote:
On Tue, 1 May 2001, Marc Saegesser wrote:
Costin,
The toLowerCase() patch look OK.
If Glenn can fix the session id stuff easily then I think
thats the best
approach right now.
Adding the jdkcompat package can't hurt - it'll be a minimal change in
SessionUtil plus the addition of 3 classes.
I'll wait for Glenn - it's probably a 15 minutes fix if we use the stuff
from 33.
Costin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 01, 2001 2:58 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Tomcat 3.2.2 beta 4
Marc,
I can quickly backport the jdkcompat package from 3.3 - it would be
cleaner than hacking generateSessionId.
The package is standalone, doesn't depend on any 3.3 feature - and
it's quite simple and effective.
Also, if you could review the following patch that will fix case
sensitive match for host names ( the patch is ported from 3.3 ).
Costin
Index: src/share/org/apache/tomcat/util/PrefixMapper.java
=== RCS
file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMa
pper.java,v
retrieving revision 1.3.2.2 diff -r1.3.2.2 PrefixMapper.java
125a126
host=host.toLowerCase();
165a167
host=host.toLowerCasse();
181a184
host=host.toLowerCase();
201c204
if( host!=null )
---
if( host!=null ) {
202a206,209
if( myMap==null ) {
myMap=(PrefixMapper)vhostMaps.get(
host.toLowerCase() );
}
}
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: Tomcat 3.2.2 beta 4
Yeah, I'll see what I can do to fix this. But It may be a day or two. Marc Saegesser wrote: Bloody hell. I was just about to launch into a wonderful tirade about why we shouldn't have change Tomcat just to work around some buggy compiler from Microsoft when I realized the real problem isn't what you think it is. The problem isn't the definition of the inner class, but the use of the PrivilegedAction interface. This interface didn't appear until JDK1.2 and my guess is that your using JDK1.1. Tomcat 3.2.x, because it implements the Servlet 1.1 specification must maintain compatibility with JDK1.1 so this is a real Tomcat bug and it will need to be fixed before releasing Tomcat 3.2.2. Glenn, can you take a look at this? -Original Message- From: Dave Oxley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 01, 2001 12:32 PM To: [EMAIL PROTECTED] Subject: RE: Tomcat 3.2.2 beta 4 I posted this before but got no response. The change to SessionUtil.java 1.5.2.2 to 1.5.2.3 (3.2.1-3.2.2b1) has caused the Microsoft Virtual Machine to fall over when running Tomcat. The M$ VM does not like internal classes defined within methods (I think this is the problem) and throws a NoClassDefFoundException. I am running Windows2000 with IE5.5(a vm update came with 5.5) although it is probably the same on all M$ VMs. This means that I cannot debug servlets in Visual J++ which is a real problem for us. (Until we find an IDE as stable and fast as VJ++!) Dave [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Tomcat 3.2.2 beta 4
RantI wish I got this sort of help from IBM. I complained about the performance of our servlet under WebSphere 3.0.2 last April and they responded saying it was our application and we spent months trying to track it down(with IBM's help), yet in November(ish) they released a patch and our application suddenly improved in performance by 4 times. It is still slower than under Tomcat./Rant Dave. [EMAIL PROTECTED] From: Marc Saegesser [EMAIL PROTECTED] Tomcat 3.2.x, because it implements the Servlet 1.1 specification must maintain compatibility with JDK1.1 so this is a real Tomcat bug and it will need to be fixed before releasing Tomcat 3.2.2. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
RE: Tomcat 3.2.2 beta 4
Costin, Let me know what you find and what the fix looks like. If its a simple fix then I'm OK with just developer testing and code review. Marc Just ship the damn thing Saegesser -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 5:37 PM To: [EMAIL PROTECTED] Subject: Re: Tomcat 3.2.2 beta 4 On Mon, 30 Apr 2001, Marc Saegesser wrote: Tomcat 3.2.2 beta 4 is available for download. If you can provide binaries for various please send them to me or update the FTP site. Thanks. Great !. Marc - one bad news, I have a bug that I think we should fix, it should be an easy fix and probably we don't need another beta for it ( I'm testing right now with beta4, maybe it's already there). The problem is related with virtual hosts - and tomcat hanging the threads when the host is not recognized. Hanging is bad - need to fix it. ( 3.3 doesn't have the problem ) Also, I'm not sure if case sensitive host is fixed in 3.2. Costin
