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 8264 invoked from network); 15 Oct 1999 00:57:39 -0000 Received: from mercury.sun.com (192.9.25.1) by apache.org with SMTP; 15 Oct 1999 00:57:39 -0000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10115 for ; Thu, 14 Oct 1999 17:57:38 -0700 (PDT) Received: from taller.eng.sun.com (taller.Eng.Sun.COM [129.144.252.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id RAA03722 for ; Thu, 14 Oct 1999 17:57:37 -0700 (PDT) Received: from eng.sun.com by taller.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA22687; Thu, 14 Oct 1999 17:57:36 -0700 Message-ID: <38067BBB.5ADA62E7@eng.sun.com> Date: Thu, 14 Oct 1999 17:56:27 -0700 From: Jason Hunter X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: ja,en,fr-BE,es,zh-TW,af,zh-CN,nl,ru,ko,tr,fr,de MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Context.java References: <19991014235741.9786.qmail@hyperreal.org> <380677D6.AF7A0163@eng.sun.com> <38067998.59499C7@eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > i don't see any verbiage in the spec that reserves anything. and it > doesn't start with javax. Yes, but the spec talks about making an additional variable available in the context. This doesn't do that -- this short circuits the getAttribute() method. With the code as it stands there's this attribute available that's not listed by getAttributeNames(), and if I assign something to "servlet.classpath" my value will never be seen. That's two violations of the spec. Spec says getAttributeNames() lists available attributes. Spec says setAttribute() with a value will let you get the value with getAttribute(). At minimum I'd think we should bury this under the rug by making it org.apache.tomcat.* so no one will know we're being nasty. I kind of prefer that to making the variable public because then it appears like other people have to implement it since the RI provides it. > the reason we didn't pick org.apache.* and picked servlet.* is > because this is also intended to be implemented by other servlet > engines.... (it would > be weird for other engines to implement org.apache.foobar...) Hmm... If other vendors are to implement it then maybe it needs to go public. Argh! "josper.servlet.classpath" maybe? I dunno anymore. Other opinions? -jh-