From Larry.Isaacs@sas.com Thu Sep 21 23:58:21 2000 Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 30609 invoked from network); 21 Sep 2000 23:58:21 -0000 Received: from merc95.us.sas.com (149.173.6.5) by locus.apache.org with SMTP; 21 Sep 2000 23:58:21 -0000 Received: from merc95.us.sas.com ([127.0.0.1]) by merc95.us.sas.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id TA8FQR8Q; Thu, 21 Sep 2000 19:57:55 -0400 Received: from 10.25.12.252 by merc95.us.sas.com (InterScan E-Mail VirusWall NT); Thu, 21 Sep 2000 19:57:55 -0400 (Eastern Daylight Time) Received: by MERC91.us.sas.com with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Sep 2000 19:57:55 -0400 Message-ID: From: Larry Isaacs To: "'tomcat-dev@jakarta.apache.org '" Subject: RE: Outstanding bugs before 3.2 final? Date: Thu, 21 Sep 2000 19:57:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N The stack traces have been restored to ExceptionHandler(). I agree that this was too big a behavior change to be committing unilaterally. I attribute the "act first, ask questions later" behavior to a somewhat foggy brain. With other things I need to do, I probably wouldn't find time to implement the configuration setting prior to Sam's window this weekend. If Tomcat 3.2 goes final this weekend, I'll save it for Tomcat 3.3. If Tomcat 3.2 doesn't go final this weekend, I think it would be worthwhile to put in. I would still recommend rebuilding beta5 with the other changes. One of them should make stack traces more useful by avoiding some of the IllegalStateExceptions that have been getting thrown on top of the real exceptions. Cheers, Larry -----Original Message----- From: Alex Chaffee To: tomcat-dev@jakarta.apache.org Sent: 9/21/00 4:37 PM Subject: Re: Outstanding bugs before 3.2 final? On Thu, Sep 21, 2000 at 03:10:08PM -0400, Larry Isaacs wrote: > I'll admit I may have overstepped a bit, going for a quick fix > giving security the priority over ease of development. I > didn't think I had time work out a configuration parameter > for server.xml. It's an understandable urge, and very common, which is why feature-freeze policies have to be applied objectively. Even though you consider it a bug, it's really changing existing behavior, thus a feature change. > IMHO, being able to easily guarantee that stack traces can't > occur is serious enough that it should be addressed in > Tomcat 3.2. Again, trying to be objective: This 'bug' hasn't hurt anyone so far, hasn't interfered with any existing applications, and hasn't been used to mount an attack (successful or otherwise) on any real or imaginary Tomcat installation -- in those terms it's certainly not serious. Let's start another thread to discuss the error-reporting behavior (descriptive and normative) and leave this one focused on what to do for the 3.2 release. > So, I willing to go with the majority. I can roll the stack > traces back into the default handling, or continue modifications > to add a configuration parameter to server.xml. What is the > feeling on this? Please roll back changes, then we will have time to discuss where and how the parameter should work, what it should be called, whether it applies to logs as well as servlets as well as JSPs, and so on. > I would assume that Tomcat 3.2 won't get any maintenance > releases the same as Tomcat 3.1. I'm reluctant to just > let Tomcat 3.2 ship because it isn't clear when Tomcat 3.3 > will be ready. ... This is a slippery slope and is not good enough to hold up 3.2 any longer. - A P.S. SHIP NOW -- Alex Chaffee mailto:alex@jguru.com jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org