[Off-Topic] Re: java.io.tempdir Problems
It sounds like maybe there is some confusion between environment variables and system properties. java.io.tempdir is a system property which presumably means it can be set on the Java command line using -Djava.io.tempdir=foo This is different then anything getenv() would return since those would be environment variables. Some of which are reflected as differently named system properties. For example, I think java.io.tempdir defaults to the TEMP environment variable under Windows and perhaps TMP under Unix or something like that. I'd have to drill into javadocs to be sure. -Paul Michael McGrady wrote: I don't know if this is helpful or not, Martin, but if you attempt System.getenv(java.io.tempdir) [which is deprecated], you get as part of the error message getenv no longer supported, use properties and -D instead: java.io.tempdir. Is that helpful? Does the -D there mean as in -Djava.io.tempdir? Michael Martin Gainty wrote: Good Afternoon Michael Perusing the Manual for Jspc at http://64.233.167.104/search?q=cache:pfbfEPvvvHUJ:www.gefionsoftware.com/Lit eWebServer/lws-jsp/ReferenceManual.pdf+TOMCAT+java.io.tempDir+-Djava.io.temp Dirhl=en formal syntax for the JSPC command jspc [options] -webapp web-app-root-dir Where option -d output-dir specifies The -d output-dir specification is the directory specified by the java.io.tempdir system property I see that there are 2 ways to specify java.io.tempdir System Property Anyone else The directory specified by the java.io.tempdirsystem property The directory specified by the java.io.tempdirsystem property The directory specified by the java.io.tempdirsystem property The directory specified by the java.io.tempdir??? Martin - Original Message - From: Michael McGrady [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 11:46 AM Subject: Re: java.io.tempdir Problems Martin, Perhaps I should add, Martin, that if I set the environment variables for java.io.tempdir and -Djava.io.tempdir in the application but not in Tomcat startup, I don't have the problem. I am a bit confused about whether to use java.io.tempdir or -Djava.io.tempdir. Can you explain a bit about that? Michael McGrady Martin Gainty wrote: Michael createTempFile employs 3 steps algorithm to locate/create tempDir 1) Attempt to retrieve the value of javax.servlet.context.tempdir from the ServletContext 2) If that's not found, attempt to retrieve the value of the init-parameter tempDir 3) If that's not found, default to the system-wide temp directory specified by the system property java.io.tempdir A)what is the value of javax.servlet.context.tempdir from the ServletContext? B)what is the value of the init-parameter tempDir? Martin- - Original Message - From: Michael McGrady [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 3:16 AM Subject: java.io.tempdir Problems I hope this is Tomcat related. If not, please accept my apologies, and give me direction. I have removed from my Tomcat 5 (Struts 1.2 using a custom taglib) service the java.io.tempdir setting because when I use the following code: File file = new File(Classpath.WEB_INF + resource+ File.separator + content_type+ File.separator + ttf + File.separator + physicalName); FileInputStream fontStream = new FileInputStream(file); Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream); font = font.deriveFont(attributes); fontStream.close(); I get temp files of around 50 - 150 kilobytes each written to the temp directory. I requested assistance on Tomcat User without an answer. Anyway, I assume that there may be a concurrency issue of somekind. Is that right? Anyone with any assistance out there? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configure Teradata data source connection
http://jakarta.apache.org/site/mail.html See the first bulleted section. -Paul Prabhjot Sodhi wrote: Hi: I am new to Java and this forum, so my apologies for asking novice queries (but u have to start one day)!!! I am working on creating a database management site using JSDK and Apache Tomcat server on my WinXp laptop. I have got a dummy test file using an applet to connect to the Teradata database. But it is failing in dearth of proper drivers. Can you please guide me set up the Teradata drivers information in the conf files, etc so that the applet can sonnect to the RDBMS and submit the query? Thanks in advance!!! Hoping for an early response. Thanks Regards, Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configure Teradata data source connection
Prabhjot Sodhi wrote: Yep it says... The User lists where you can send questions and comments about configuration, setup, usage and other user types of questions. I wish to know about the server configuration. So send it to the user's list. Since that's where configuration would be discussed. This is the developer list, where people discuss bugs and other internal tomcatty goodness. -Paul Thanks Regards, Pete Senior System Analyst, IBM Global Services, 202 Coward Street, Mascot. Ph (O) : +61 2 9691 3589 mail-id: [EMAIL PROTECTED] ** This communication may contain CONFIDENTIAL or copyright information of IBM Australia Limited, (ABN 79 000 024 733). If you are not an intended recipient, you MUST NOT keep, forward, copy, use, save or rely on this communication, and any such action is unauthorised and prohibited. If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery, and then delete both it and your reply. Thank you. ** Paul Speed [EMAIL PROTECTED] 22/09/2004 02:15 PM Please respond to Tomcat Developers List To Tomcat Developers List [EMAIL PROTECTED] cc Subject Re: Configure Teradata data source connection http://jakarta.apache.org/site/mail.html See the first bulleted section. -Paul Prabhjot Sodhi wrote: Hi: I am new to Java and this forum, so my apologies for asking novice queries (but u have to start one day)!!! I am working on creating a database management site using JSDK and Apache Tomcat server on my WinXp laptop. I have got a dummy test file using an applet to connect to the Teradata database. But it is failing in dearth of proper drivers. Can you please guide me set up the Teradata drivers information in the conf files, etc so that the applet can sonnect to the RDBMS and submit the query? Thanks in advance!!! Hoping for an early response. Thanks Regards, Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
Amy Roh wrote:
[EMAIL PROTECTED] wrote:
amyroh 2004/09/20 10:51:28
Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
Log:
Remove verbose.
-if (verbose) {
-if (log.isDebugEnabled())
-log.debug(constant pool count: +
constantPoolCount);
-}
+log(constant pool count: + constantPoolCount);
You need to keep if (log.isDebugEnabled()), otherwise, zillions of
Strings will be created for no reason (as the parameter of your method
will have to be created).
I have added the following log helper method so I don't have to do if
(log.isDebugEnabled()) everytime I use log.debug()
+
+private static void log(String msg) {
+if (log.isDebugEnabled())
+log.debug(msg);
+}
+
}
Amy
+log(constant pool count: + constantPoolCount);
But even to call your log() method, a String will need to be created
that combines the constant pool count: with a
String.valueOf(constantPoolCount). Even if it's just going to be thrown
away.
-Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi ExpressionParseTree.java ExpressionTokenizer.java SSIConditional.java SSIConditionalState.java ByteArrayServletOutputStream.java ResponseIncludeWrapper.java SSICommand.java SSIConfig.java SSIEcho.java SSIExec.java SSIExternalResolver.java SSIFlastmod.java SSIFsize.java SSIInclude.java SSIMediator.java SSIPrintenv.java SSIProcessor.java SSIServlet.java SSIServletExternalResolver.java SSIServletRequestUtil.java SSISet.java SSIStopProcessingException.java
Yay! My code is back. :) -Paul [EMAIL PROTECTED] wrote: funkman 2004/09/01 11:33:34 Modified:catalina/src/share/org/apache/catalina Globals.java catalina/src/share/org/apache/catalina/ssi ByteArrayServletOutputStream.java ResponseIncludeWrapper.java SSICommand.java SSIConfig.java SSIEcho.java SSIExec.java SSIExternalResolver.java SSIFlastmod.java SSIFsize.java SSIInclude.java SSIMediator.java SSIPrintenv.java SSIProcessor.java SSIServlet.java SSIServletExternalResolver.java SSIServletRequestUtil.java SSISet.java SSIStopProcessingException.java Added: catalina/src/share/org/apache/catalina/ssi ExpressionParseTree.java ExpressionTokenizer.java SSIConditional.java SSIConditionalState.java Log: Backport from 4.1 the ssi if else logic Revision ChangesPath 1.11 +12 -1 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Globals.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Globals.java.diff?r1=1.10r2=1.11 1.5 +23 -21jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ByteArrayServletOutputStream.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ByteArrayServletOutputStream.java.diff?r1=1.4r2=1.5 1.5 +57 -57jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ResponseIncludeWrapper.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/ResponseIncludeWrapper.java.diff?r1=1.4r2=1.5 1.4 +29 -28jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSICommand.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSICommand.java.diff?r1=1.3r2=1.4 1.4 +34 -40jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java.diff?r1=1.3r2=1.4 1.3 +44 -53jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIEcho.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIEcho.java.diff?r1=1.2r2=1.3 1.4 +49 -55jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExec.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExec.java.diff?r1=1.3r2=1.4 1.4 +46 -39jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExternalResolver.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIExternalResolver.java.diff?r1=1.3r2=1.4 1.4 +47 -52jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFlastmod.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFlastmod.java.diff?r1=1.3r2=1.4 1.3 +76 -82jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFsize.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIFsize.java.diff?r1=1.2r2=1.3 1.4 +39 -45jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIInclude.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIInclude.java.diff?r1=1.3r2=1.4 1.4 +258 -176 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIMediator.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIMediator.java.diff?r1=1.3r2=1.4 1.3 +36 -43jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIPrintenv.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIPrintenv.java.diff?r1=1.2r2=1.3 1.4 +224 -193 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIProcessor.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIProcessor.java.diff?r1=1.3r2=1.4 1.8 +87 -99jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java.diff?r1=1.7r2=1.8 1.4 +379 -356 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ssi/SSIServletExternalResolver.java
Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config context.xml
To configure space tabs on Emacs... quoted from: http://www.student.northpark.edu/pemente/emacs_tabs.htm For this session, force Emacs to indent with spaces, never with TABs: M-x set-variableRET indent-tabs-modeRET nil Permanently force Emacs to indent with spaces, never with TABs: (setq-default indent-tabs-mode nil); # put this in your .emacs file Or, to just one spot convert tabs to spaces for a given selection: M-x untabify I don't have an emacs up and running at the moment so can't verify, but it sounds right from what I remember. As I recall, untabify requires selecting the contents of the buffer first. -Paul Shapira, Yoav wrote: Hi, I'm actually working in emacs over PuTTY due to some weird network/firewall (mis)configuration issues here at work, so it's a pain for me to fix the tabs at this time ;( Yoav Shapira Millennium Research Informatics -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 10:53 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/webapps/docs/config context.xml [EMAIL PROTECTED] wrote: yoavs 2004/08/31 07:50:41 Modified:catalina/src/share/org/apache/catalina/core Tag: TOMCAT_5_0 StandardContext.java webapps/docs Tag: TOMCAT_5_0 changelog.xml webapps/docs/config Tag: TOMCAT_5_0 context.xml Log: Added StandardContext processTlds attribute, added context configuration references docs for processTlds, tldValidation, tldNamespaceAware. I can feel two more commits are coming in shortly ;) Can you fix the tabs at the same time ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hin Kan Lee/Prymnewey is out of the office.
And give his auto-responder admin a big wedgie too. -Paul Mladen Turk wrote: Can someone kill this guy? -Original Message- From: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spam vulnerability at apache
Everyone on the list received these e-mails since they were sent to the list. No harvesting was necessary. As I understand it, the apache mailing lists are promiscuous in a way and will easily/accidentally let any e-mail address subscribe as long as it sends a reply to a subscribe confirmation e-mail. This means script kiddies or whoever can simply pretend to be [EMAIL PROTECTED] and subscribe to the mailing list. Since these kinds of support e-mails get auto-responded and because most sysadmins can't seem to be bothered to ignore e-mails of type bulk, these support addresses get subscribed and can then auto-reply to every message. The list moderators are pretty quick about removing the offending addresses, but it doesn't stop a few e-mails from sneaking through. The really painful part is how often this is happening lately. Some people seem to have way to much time on their hands and an abnormal sense of humor. Just a lurker's two cents. -Paul Reshat Sabiq wrote: Hi, I extremely apologize for this message, but i think this needs to be figured out. I just yesterday registered my new email address with tomcat-dev, and i received the spam below almost immediately thereafter. Only a few people are aware of this email address, so the origin of spam info 99% appears to be tomcat-dev registration. Is there any chance that DNS gets resolved to one of several IPs, one of which collects these emails and uses them for spam (or perhaps is infected with a virus)? I would look for any IPs based in russia as the prime suspects, because this email contains russian text and appears to be originated there. What's worse is that 25 minutes after this spam, i received another one of similar content. Please help save me and others from this plague of the Internet. I entrusted apache.org with this address, and hope we can keep it between us. P.S. If there are other people who received similar emails, please let me, the admins, or the list know. If you let only me know, i will accumulate the number of people affected and forward this to an admin. P.P.S. I see that emails are protected in the archives publicly published, and i think this issue is in the same category. Thanks, rsa/ [EMAIL PROTECTED] wrote: russian(win-1251): ! Photo document, . . , [TID#4977]. , : [TID#4977] (subject) . (reply). C , -10 http://www.m-10.ru english: Greetings, This message has been automatically generated in response to your message regarding Photo document, the content of which appears below. There is no need to reply to it now. Support has received your message and it has been assigned a ticket ID of [TID#4977]. Please include the string: [TID#4977] in the subject line of all future correspondence about this problem. To do so, you may reply to this message. WBR, Support Team Hosting Operator M-10 http://www.m-10.ru Original Message- Please, photo document. Yours sincerely +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new F-Secure OnlineAntiVirus +++ Visit us: www.f-secure.com -Headers Follow-- Received: from [EMAIL PROTECTED] by office.m-10.ru (CommuniGate Pro GROUP 4.1.8) with GROUP id 1745058; Mon, 12 Apr 2004 17:13:05 +0400 Received: from [62.5.188.222] (HELO office.m-10.ru) by office.m-10.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1745042 for [EMAIL PROTECTED]; Mon, 12 Apr 2004 17:12:58 +0400 X-Antivirus: Checked by Dr.Web (http://www.drweb.net) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Photo document Date: Mon, 12 Apr 2004 17:11:48 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0016=_NextPart_000_0016 X-Priority: 3 X-Msmail-Priority: Normal Message-Id: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spam vulnerability at apache
I think this is a combination of a misconfigured mail server at one800.net and a bad e-mail address subscribed to the list. The mail server is badly configured because it replied to sender instead of the reply-to address. If it had replied to the reply-to address you would never have seen it and the mailing list software would likely have disabled the address. It's probably also a recent thing. -Paul Reshat Sabiq wrote: I'm sorry to report that sending the message below, caused the following to show up in my mail box. There is definitely something fishy with the apache mail servers. This does not happen when i send an email to a non-apache address. Please, let's fix this: Your Mail has been bounced from the OutPost/1.800eMail Server Because [EMAIL PROTECTED] is not a valid username Original message, less any attachments, follows: ... Reshat Sabiq wrote: Hi, I extremely apologize for this message, but i think this needs to be figured out. I just yesterday registered my new email address with tomcat-dev, and i received the spam below almost immediately thereafter. Only a few people are aware of this email address, so the origin of spam info 99% appears to be tomcat-dev registration. Is there any chance that DNS gets resolved to one of several IPs, one of which collects these emails and uses them for spam (or perhaps is infected with a virus)? I would look for any IPs based in russia as the prime suspects, because this email contains russian text and appears to be originated there. What's worse is that 25 minutes after this spam, i received another one of similar content. Please help save me and others from this plague of the Internet. I entrusted apache.org with this address, and hope we can keep it between us. P.S. If there are other people who received similar emails, please let me, the admins, or the list know. If you let only me know, i will accumulate the number of people affected and forward this to an admin. P.P.S. I see that emails are protected in the archives publicly published, and i think this issue is in the same category. Thanks, rsa/ [EMAIL PROTECTED] wrote: russian(win-1251): ! Photo document, . . , [TID#4977]. , : [TID#4977] (subject) . (reply). C , -10 http://www.m-10.ru english: Greetings, This message has been automatically generated in response to your message regarding Photo document, the content of which appears below. There is no need to reply to it now. Support has received your message and it has been assigned a ticket ID of [TID#4977]. Please include the string: [TID#4977] in the subject line of all future correspondence about this problem. To do so, you may reply to this message. WBR, Support Team Hosting Operator M-10 http://www.m-10.ru Original Message- Please, photo document. Yours sincerely +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new F-Secure OnlineAntiVirus +++ Visit us: www.f-secure.com -Headers Follow-- Received: from [EMAIL PROTECTED] by office.m-10.ru (CommuniGate Pro GROUP 4.1.8) with GROUP id 1745058; Mon, 12 Apr 2004 17:13:05 +0400 Received: from [62.5.188.222] (HELO office.m-10.ru) by office.m-10.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1745042 for [EMAIL PROTECTED]; Mon, 12 Apr 2004 17:12:58 +0400 X-Antivirus: Checked by Dr.Web (http://www.drweb.net) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Photo document Date: Mon, 12 Apr 2004 17:11:48 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_NextPart_000_0016=_NextPart_000_0016 X-Priority: 3 X-Msmail-Priority: Normal Message-Id: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returned mail: Delivery Failed
I remember when these lists were moderated. Those were the days. -Paul Martin Gainty wrote: Personally I was thinking of something more politically correct. There is not much room for misinterpretation of your statement Is there a way to unsubscribe these people so we do not get spammed by them? Martin - Original Message - From: Lee [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, March 15, 2004 8:01 AM Subject: Re: Returned mail: Delivery Failed FUCK OFF --- [EMAIL PROTECTED] wrote: The attempted delivery of Returned mail: Delivery Failed failed for the following reason: mail from 202.57.162.11 refused, blocked by: proxies.relays.monkeys.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returned mail: Delivery Failed
It seemed to me that in the old days, posts were held until a moderator let them through. You had to be put on an approved list to have direct posting access. At least, that's how the posting delay for new subscribers was explained. As I undertand it, none of these messages would have made it through under that system. I wouldn't call the current situation as moderated so much as managed. Is there a reason that the developers list allows posting from non-subscribers? Or are these troubled addresses actually fully subscribed? -Paul Shapira, Yoav wrote: Hi, The lists are moderated ;) Ignacio Ortega moderated them by himself for a long time, and I've helped him out for the past year and change, to the point where he's not really that active anymore ;) Moderating the lists is by and large an unglamorous, thankless job. Like all ASF things, it's done on our free time without compensation. I don't check my email on weekends, hence the delayed response to this particular one. I am happy to help out with moderating this list. I get just as annoyed as everyone else with spam. What is the process for becoming a moderator? Will you commit to checking the lists on weekends? I have the weekdays covered pretty much. If you want to continue this discussion privately/off-list, feel free ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returned mail: Delivery Failed
Shapira, Yoav wrote: Hi, It seemed to me that in the old days, posts were held until a moderator let them through. That was true for some lists. Very few lists are so light in traffic that that's possible now. Ah. The way I understood it before was that new subscribers were allowed to post but their posts would get moderated until putting them on a good poster list. I guess I was mistaken about the last part, but it would be a pretty good system. subscribers was explained. As I undertand it, none of these messages would have made it through under that system. That's true, but that system is not feasible for tomcat-dev and tomcat-user, as it requires moderators to screen thousands of messages daily. I wouldn't call the current situation as moderated so much as managed. Is there a reason that the developers list allows posting from non-subscribers? Or are these troubled addresses actually fully subscribed? All these addresses are fully subscribed (i.e. they responded to the subscription confirmation message). Only subscribed addresses may post here. Thanks for the information. I'm not one to sit by and critique something that I'm not willing to help out on. So, I'd be willing to help out if needed. I'm not a committer, but I've been reading this list for years. -Paul Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returned mail: Delivery Failed
David Rees wrote: Shapira, Yoav wrote: I wouldn't call the current situation as moderated so much as managed. Is there a reason that the developers list allows posting from non-subscribers? Or are these troubled addresses actually fully subscribed? All these addresses are fully subscribed (i.e. they responded to the subscription confirmation message). Only subscribed addresses may post here. Note that most of these auto-responders are brain-dead enough that anyone can unsubscribe them by sending a blank message to the following addresses: Good point. As convenient as the reply to confirm system is, maybe it's time for mailing list program authors to come up with something better. Is this a configurable option for this list's software? (ezmail?) -Paul [EMAIL PROTECTED] Replace tomcat-dev with tomcat-user for auto-responders spamming that list. Unfortunately, as easy as it is to unsubscribe these addresses, they can become subscribed again so they need to be blacklisted. Yoav, you currently handle blacklisting of these addresses, correct? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Email account utilization warning.
It is a little strange that noone from the apache team has stepped forward to clarify that these are fake... since they are being sent to an apache mailing list after all. The clues I had that it was a fake: 1) Sent to an apache/jakarta mailing list... by apache.org. 2) Really poor grammar in the message. (Ok, who am I kidding? ;) 3) I started getting similar e-mails from my own domain. ;) But it's probably given more than a few people pause. -Paul Mark Roth wrote: Hi Michael, I think the message itself is from a clever virus that is trying to get you to open the attachment. I thought I saw another such email go by my Inbox the other day that was signed The somethingelse.com team. Fortunately, us Linux and Solaris folk don't have to worry about such things :) --- Mark Roth, Java Software JSP 2.0 Specification Lead Sun Microsystems, Inc. Michael McGrady wrote: What is this about? I am sure of one thing, I did not improperly use anything. I don't know what you mean about resign[ing my]account information either. Since there was no attached file, I assume my security picked up an attempt to pass on a virus. Anyone else seeing these? Michael At 01:07 AM 3/8/2004, you wrote: Dear user, the management of Apache.org mailing system wants to let you know that, Your e-mail account will be disabled because of improper using in next three days, if you are still wishing to use it, please, resign your account information. For more information see the attached file. Attached file protected with the password for security reasons. Password is 46855. Kind regards, The Apache.org team http://www.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem
Vano Beridze wrote: jean-frederic clere wrote: +++ --- Additional Comments From Remy Maucherat 2004-02-19 19:44 --- Yes, but not doing so is too complex to implement overall (since you would have to parse the descriptor to know what to do). +++ For me that is a good explaination as severity of the bug is enhancement. Have you read the comment next to that message? I'm saying that it's not necessary to parse the descriptor. If I'm wrong then tell me instead of closing the bug as wontfix again. Then propose a patch for your problem I will aply it :-) If it would be a critical problem for me I would propose :) I was just impressed by so aggresive behaviour. Tomcat list was always friendly to me. Don't see it as aggressive behavior. See at as someone who tries to keep the bug database trimmed to only those things that someone cares enough about to implement. It doesn't really serve any purpose if it's filled with 500 enhancements that noone wants to implement. Just a lurker's opinion, -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [5.0] JSP performance ...
I think the performance improvement was because the Strings were converted to char[] arrays during servlet init, and not at every request. It seems to me as if that would make a difference. -Paul Kin-Man Chung wrote: I took a look at o.a.j.runtime.JspWriterImpl and the methods write(String s, int off, int len) and write(char cbuf[], int off, int len) in particualr, and failed to see any performance gain of the 2nd over the first. They are very similar, the only different is that the first uses String.getChars while the second uses System.arraycopy, but those two methods should be on par in terms of performance. That is, I don't see any extra unnecessary copies. Perhasp the culprit is those extra writes? -Kin-man Date: Mon, 08 Sep 2003 23:03:19 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: AW: [5.0] JSP performance ... To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: This seems easy enough to implement, so I'll look into it. Concatenating texts is also on my list, and it should help a little in this case. That would be awesome. The test had a *lot* of writes, so this would save hundreds of write invocations (as well as making them faster as it would user char arrays). JSP performance should be really good with that change. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java
Clearly you guys make it way to easy to subscribe to the list. ;) -Paul Bill Barker wrote: Ok, I tried asking nice, and just got a machine-response. Could whoever is currently Moderator for this list helpfully allow minimalist to unsubscribe ;-). - Original Message - From: Minimalist Manager [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 11:45 PM Subject: Re: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java ERROR: There is no such list JKMAIN.JAVA here. SOLUTION: Send a message to [EMAIL PROTECTED] with a subject of 'info' (no quotes) for a list of available mailing lists. -- Sincerely, the Minimalist - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/tester/web/golden SSIConditional09.txt
Thanks Dan. Now I have my 15 milliseconds of fame back. ;)
I'll see if I can test the updates with my site soon.
-Paul Speed
[EMAIL PROTECTED] wrote:
dsandberg2002/11/25 02:15:43
Modified:catalina/src/share/org/apache/catalina/ssi SSICommand.java
SSIConfig.java SSIEcho.java SSIExec.java
SSIFlastmod.java SSIFsize.java SSIInclude.java
SSIMediator.java SSIPrintenv.java SSIProcessor.java
SSISet.java SSIStopProcessingException.java
tester/src/bin tester.xml
Added: catalina/src/share/org/apache/catalina/ssi
ExpressionParseTree.java ExpressionTokenizer.java
SSIConditional.java SSIConditionalState.java
tester/web SSIConditional09.shtml
tester/web/golden SSIConditional09.txt
Log:
Added back Paul Speed's conditional SSI enhancement. Updated code/regression
tests to better emulate Apache SSI. Fixed bug w/ expression parser's handling of
literals.
Revision ChangesPath
1.2 +5 -3
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSICommand.java
Index: SSICommand.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSICommand.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SSICommand.java 24 May 2002 16:35:39 - 1.1
+++ SSICommand.java 25 Nov 2002 10:15:42 - 1.2
@@ -79,12 +79,14 @@
* Write the output of the command to the writer.
*
* @param ssiMediator the ssi mediator
+ * @param commandName the name of the actual command ( ie. echo )
* @param paramNames The parameter names
* @param paramValues The parameter values
* @param writer the writer to output to
* @throws SSIStopProcessingException if SSI processing should be aborted
*/
public void process(SSIMediator ssiMediator,
+ String commandName,
String[] paramNames,
String[] paramValues,
PrintWriter writer) throws SSIStopProcessingException;
1.3 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java
Index: SSIConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIConfig.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SSIConfig.java24 Nov 2002 06:22:36 - 1.2
+++ SSIConfig.java25 Nov 2002 10:15:42 - 1.3
@@ -72,6 +72,7 @@
* Implements the Server-side #exec command
*
* @author Bip Thelin
+ * @author Paul Speed
* @author Dan Sandberg
* @version $Revision$, $Date$
*/
@@ -80,6 +81,7 @@
* @see SSICommand
*/
public void process(SSIMediator ssiMediator,
+ String commandName,
String[] paramNames,
String[] paramValues,
PrintWriter writer ) {
1.2 +6 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIEcho.java
Index: SSIEcho.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIEcho.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SSIEcho.java 24 May 2002 04:38:58 - 1.1
+++ SSIEcho.java 25 Nov 2002 10:15:42 - 1.2
@@ -71,6 +71,7 @@
* Return the result associated with the supplied Server Variable.
*
* @author Bip Thelin
+ * @author Paul Speed
* @author Dan Sandberg
* @version $Revision$, $Date$
*/
@@ -82,6 +83,7 @@
* @see SSICommand
*/
public void process(SSIMediator ssiMediator,
+ String commandName,
String[] paramNames,
String[] paramValues,
PrintWriter writer) {
1.3 +7 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIExec.java
Index: SSIExec.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIExec.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SSIExec.java 24 Nov 2002 06:22:36 - 1.2
+++ SSIExec.java 25 Nov 2002 10:15:42 - 1.3
@@ -89,6 +89,7 @@
*
* @author Bip Thelin
* @author Amy Roh
+ * @author Paul Speed
* @author Dan
Re: Why can I not use attributes lang and maxRows in a custom tag
The Java beans API requires getters. It does not require setters. No setter means the property is read-only. There's no such thing as write-only in the Java beans API. A getter is the only way to determine what the type of the property is since there can be only one getter with a particular name. The Java beans API is all about deducing all of this information at runtime... so it must be able to figure this out. (For PropertyDescriptors and such.) Not 100% useful as a way to do simple reflection though. -Paul [EMAIL PROTECTED] wrote: If Tomcat uses the beans API in Java to do the reflection for calling these methods, then that is probably why. It insists on having a valid get and set method for an attribute for some reason. I ran into this once when I only wanted to have getters with no setters, and I couldn't find a way around it other than to use reflection directly (mind you, I was in a hurry, so I didn't try too hard). -- Rob Jim Cobban [EMAIL PROTECTED]To: Jan Luehe [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Why can I not use attributes lang and maxRows in a custom tag 23/11/2002 11:17 AM Please respond to Tomcat Developers List - Original Message - From: Jan Luehe [EMAIL PROTECTED] Subject: Re: Why can I not use attributes lang and maxRows in a custom tag Tomcat 4.1.12 does not accept a custom tag with attributes lang or maxRows. When I asked about this on the Tomcat users list I was informed that it also does not accept the attribute class. Specifically if I define those attributes then when the jsp is compiled I get an unable to find setter error. If I replace them with similar but meaningless attribute names the page compiles correctly. This can't be true. For example, JSTL defines an attribute named 'maxRows' for its sql:query action. I am not aware of any naming restrictions for custom tag attributes. Are you sure the tag handler for your custom action defines an approriate setter method for the attributes in question? I kept experimenting and found exactly what it was that Tomcat disliked about my attribute. It was not the name. It was not the presence or absence of the set method. It was that there was also a get method which did not return String! Since Tomcat does not use the get method I do not understand why it cares whether or not one is present or what its signature is. But as soon as I change the name of the get method so it did not match the set method Tomcat merrily accepted the tag. For me this is now an issue of documentation. I have searched the JSP 1.2 spec using every term I can think of and I cannot find where it specifies the characteristics of the set method for an attribute on a custom tag. I have therefore been depending upon the description of this capability in Marty Hall's book. If the JSP specification, and Tomcat, have a legitimate reason for looking at the characteristics of the get method when deciding whether or not to use the set method, then that should be documented. Otherwise the behavior is frankly mysterious. Thank you for responding. When a week went by without a response I unsubscribed from the list, so the CC on this message may be discarded. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] If you received this e-mail in error please delete it and notify the sender as soon as possible. The contents of this e-mail may be confidential and the unauthorized use, copying, or dissemination of it and any attachments to it, is prohibited. Internet communications are not secure and Hyperion does not, therefore, accept legal responsibility for the contents of this message nor for any damage caused by viruses. The views expressed here do not necessarily represent those of Hyperion. For more information about Hyperion, please visit our Web site at www.hyperion.com -- 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: Why can I not use attributes lang and maxRows in a customtag
Craig R. McClanahan wrote: On Sat, 23 Nov 2002, Paul Speed wrote: Date: Sat, 23 Nov 2002 18:50:34 -0500 From: Paul Speed [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Why can I not use attributes lang and maxRows in a custom tag The Java beans API requires getters. It does not require setters. No setter means the property is read-only. There's no such thing as write-only in the Java beans API. That turns out not to be the case. Section 8.3.1 of the JavaBeans Specification makes it clear that you can have either a read-only or a write-only property, in addition to a read-write property. Ok, I'll admit this is true... however, (and it may be a personal problem) the only way I ever got write-only properties to work was to setup bean info. I've had problems getting the introspector to find these automatically... especially if you have more than one setter. Whereas, if you add a properly typed getter, everything magically works without the extra trouble. I knew as soon as I made an absolute statement right after waking up from a nap, I'd regret it. ;) Now if beans would just get multi-valued properties right... but that's another story. :) -Paul JSP custom tags are a pretty good use case for write-only properties -- the JSP contracts only require an ability to *set* the property values; there is no requirement that the attribute values be made publicly available to any other class. After all, the tag implementation class will have internal access to the set value, by referencing whatever instance variable the setter stored it in. A getter is the only way to determine what the type of the property is since there can be only one getter with a particular name. The Java beans API is all about deducing all of this information at runtime... so it must be able to figure this out. (For PropertyDescriptors and such.) The user's original problem wasn't that they had a write-only property. The problem was that the data type of the getter and setter did not match, which violates the design patterns of Section 8.3. Therefore, te JavaBeans introspector does not consider this to be an actual JavaBeans property. Not 100% useful as a way to do simple reflection though. -Paul Craig -- 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: problems with SSI extensions
These worked at one time. Then that entire version of SSI was
clobbered and replaced with a version that only supported a subset
of the commands. None of my clobbered rewrite has been ported
forward again and I haven't had the time (or motivation) to rewrite
my rewrite again and try to get a patch committed.
I only mention this so that if someone wants to scratch this particular
itch they know that there's code in the CVS attic that does this.
They'd just have to port it somehow. Might save someone some time.
-Paul
Richard Hallier wrote:
Hello,
Tomcat 4.1.12 with SSI enabled
Basic functions work well, but i'm in trouble with :
1/ !--#if is not supported (i've got an unknown command), maybe it's
normal
2/ This command in my .shtm : !--#include virtual=${QUERY_STRING} --
generates the following error:
2002-11-19 21:11:20 ssi: #include--Couldn't include file: ${QUERY_STRING}
java.io.IOException: Couldn't find file: /${QUERY_STRING}
Thank you for your help.
--
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: Vote results + Security Audit redirection
[reposting from my subscribed account] For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Anyway, just my non-binding $0.02, -Paul Ignacio J. Ortega wrote: From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
[reposting from my subscribed account] For what it's worth, I'm not disagreeing that there needs to be another list. Clearly, really serious security issues should at least be delayed from being made public. However, I think there needs to be a bit more paranoia about how this list manifests itself. Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for determining what should be discussed on the other list, it's all over. Sort of like the U.S. congress being in charge of their own pay raises. As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) Anyway, just my non-binding $0.02, -Paul Ignacio J. Ortega wrote: From: Paul Speed [mailto:pspeed;progeeks.com] Sent: Thursday, October 17, 2002 4:15 PM The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. Not really, CC'ed threads are easy to manage simply reply to all and things goes smoothly, the problem the new mail list tries to solve, is much more simple, Are those how can fix and are interested in the problem, informed quickly? are those interested not forgotten in some part of the eamil theread? are part of the thread more private than intended only because some people unadvertely forgotten some other fellow email in the CC?.. all of that can be alleviated if not solved simply by using a closed maillist.. Fixes are ever public, and CVs comments are more than sufficient to see the problem and the fix being done.. so the open end of all threads in the new list is guaranteed now.. Saludos, Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Sorry about the double post. It looked like the other one went out with the original non-subscriber address. -Paul Paul Speed wrote: [reposting from my subscribed account] [snip] -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Costin Manolache wrote: Paul Speed wrote: Any behind closed doors discussions have the potential for alienating the non-committer community. Determining what conversations are appropriate for this other list is a very slippery slope. It's :-) Yes, I think I know what you mean. Trust me, you're not the only one who things that, and 'closed doors' is the last thing I want. I see it more like an 'open doors' situation ( private Cc: - a larger group ). Phew. I feel better already. Seriously. already been proposed that votes for new committers be discussed there first. What's next? And if the other list starts being used for No, I just sugested that it would be nice to avoid some of the incidents that happened in the past. I admit - in most cases I do send a private mail to the person and few private mails to some other commiters to ask their opinions. Jumping directly and making the proposal is not the best strategy IMO, and at least I never did that without at least a second opinion. So the only thing that will change is having this 'do you think it's a good idea' sent to everyone. And avoid 'no, I don't think so because ...' in the public list. Yeah, I see where you're coming from, but some of that should end up public. Fine line. For example, let me paint a (hopefully) brief picture. I'm probably one of your more avid non-committers: I still read (and to some extent participate) even though I haven't used tomcat professionally in over two years. I've been on the list for maybe three years... lost count. During a period of unemployment a year ago, my itch was to bring the SSI stuff up to spec and so I mostly rewrote the SSI servlet and associated classes. These were accepted and committed to head. All was well and even kept up on recommending people stay away from the older version when issues would crop up in bugzilla. Eventually I got a job and spent a few months off the list. During that time someone else also found the old SSI code lacking and rewrote it again without ever noticing that there was alreay a newer better version. Unfortunately, the committers didn't notice either and all of my work was blown away. Sad, but such is life sometimes. Anyway, long story short, this person was made committer shorlty after that, persumably just to maintain the SSI code. There was some controversy on this list at the time about whether or not this was appropriate since there hadn't been many other contributions from said person. If I hadn't witnessed this conversation, it really would have added insult to injury when they were made committer. Instead, it was no big deal at all other than a little disappointment. So, that's probably why your earlier committer vote proposal comment grabbed my interest in this thread. Ok, so not brief. Oh well, -Paul As a non-committer but long-time subscriber to this list, my opinion is that _all_ messages on the other list must absolutely show up here eventually, at some delay. Otherwise, there is no longer any transparency. (This is also the biggest reason it's better than CCed e-mails; because the messages will always be public at some point.) I agree for most part. And I think that an all-commiter list is better than Cc: chains with few people, it's more inclusive and better for everyone. Regarding all-messages to the list - I agree, all information should get to tomcat-dev, ( unless whoever posts it wants to keep it private ). One of the reasons Cc: is used is because some people don't want certain issues to become public ( for example me asking Remy really dumb questions on JNDI :-). I think it would be better if most of the Cc: will go to the commiters list, and most of the commiters list will go to tomcat-dev. Both are improvements over current situation IMO. And besides - if someone really wants to be on the commiters list, there is a way to do it, and we are all happy to get more people involved ( and on the list ) :-) Costin -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Vote results + Security Audit redirection
Costin Manolache wrote: IAS wrote: I got a little bit curious about why finding bugs relevant to security and fixing them should be not open. I don't doubt that there are both merit and demerit of discussing those critical issues with full disclosure. Absolutely there may be some peril that some (bad) people can misuse the opened information purely exposed to help tomcat community to collaborate against security problems. Regardless of such understanding, I feel sorry about loss of the potential that more openness can give more people chances to figure out the shared troubles and remind them of importance of security at an early stage. The problem is when the bad people find out about the security problems before they are fixed. I'm not saying that anyone subscribe to tomcat-dev is 'bad', but the list is archived and google searchable and has a lot of subscribers. All information will become public - it's just that I think it is better ( at least for the bugs we discover ) to first have a fix. You probably noticed most of the announcements on security issues from apache and many other organizations include a fix or at least workaround. It is a common practice to have the security issues forwarded first to some commiters, and then made public. And I think this should be true not only for bugs found from outside, but also from inside. There was also some comment about other special issues, which has not been clear to me yet. It's not clear to me either :-) Maybe short notices like I want to propose X as a commiter, does anyone has any objection ? - to avoid some of the unpleasant things we had in the past. That's the only example I can think of. Except, this is exactly the kind of thing I think should stay on this list. A slippery slope indeed. Maybe all tomcat-dev traffic should be vetted through this other list first and posted here at a 1 to 2 week delay, just in case something is mentioned that might turn out with analysis to be a security risk. The more security through obscurity the better, right? ;) The nice thing about your current way of dicussing security issues (CC e-mail threads) is that it's a real pain in the butt. In other words, likely only to be used in the cases of necessity. I think the only way you can keep the new list from feeling like a double secret exclusive club is to forward _all_ traffic at some delay and keep that traffic to a minimum. Otherwise, it's going to start feeling an awful lot like some of you felt when working for Sun were having extended offline discussions that eventually just popped up here as a pre-resolved proposal/issue. Wish I could site a specific case, but it was a while ago. It will be as frustrating as waiting for a JSR public draft. Sorry, I didn't mean to go on so long originally. There's just something about all this that worries me a bit. Perhaps because noone else seems particularly concerned. Oh well, what do I know. -Paul Basically, I hope every discussion among Apache Jakarta Project developers would be as open and transparent as possible. Same for me. My main goal was to get all active commiters involved in future security issues. We are all equally responsible. 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]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
+ return java.net.URLEncoder.encode(\\ + + v + );
I know I'm being pedantic, but it's a small pet peeve of mine. :)
How about:
return java.net.URLEncoder.encode( String.valueOf(v) );
Should do the same thing without all the behind-the-scenes
StringBuffer stuff.
-Paul Speed
[EMAIL PROTECTED] wrote:
remm2002/09/05 04:27:20
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Force the convesion of the value to a string.
- Note: I am not convinced this is a compliance issue (and it looks like bad design
to pass an object or null); this just reverts back the old behavior.
Revision ChangesPath
1.90 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- Generator.java4 Sep 2002 23:45:29 - 1.89
+++ Generator.java5 Sep 2002 11:27:19 - 1.90
@@ -749,7 +749,7 @@
_jspx_fnmap );
}
if (encode) {
- return java.net.URLEncoder.encode( + v + );
+ return java.net.URLEncoder.encode(\\ + + v + );
}
return v;
} else if( attr.isNamedAttribute() ) {
--
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: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Paul Speed wrote:
+ return java.net.URLEncoder.encode(\\ + + v + );
I know I'm being pedantic, but it's a small pet peeve of mine. :)
How about:
return java.net.URLEncoder.encode( String.valueOf(v) );
So much for attention to details...
return java.net.URLEncoder.encode( String.valueOf( + v + ) );
-Paul
Should do the same thing without all the behind-the-scenes
StringBuffer stuff.
-Paul Speed
[EMAIL PROTECTED] wrote:
remm2002/09/05 04:27:20
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Force the convesion of the value to a string.
- Note: I am not convinced this is a compliance issue (and it looks like bad
design
to pass an object or null); this just reverts back the old behavior.
Revision ChangesPath
1.90 +4 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.89
retrieving revision 1.90
diff -u -r1.89 -r1.90
--- Generator.java4 Sep 2002 23:45:29 - 1.89
+++ Generator.java5 Sep 2002 11:27:19 - 1.90
@@ -749,7 +749,7 @@
_jspx_fnmap );
}
if (encode) {
- return java.net.URLEncoder.encode( + v + );
+ return java.net.URLEncoder.encode(\\ + + v + );
}
return v;
} else if( attr.isNamedAttribute() ) {
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.34 diff -r1.34 web.xml 150d149 157a157 !-- This will generally SLOW-DOWN processing. -- 169c169,170 !-- the server root? (0=false, 1=true) [0]-- --- !-- the server root? See note below. -- !-- (0=false, 1=true) [0] -- 171,174c172,177 !-- ignoreUnsupportedDirective -- !-- Should unknown or misspelled Ssi directives-- !-- be ignored and no errors shown?-- !-- (0=false, 1=true) [1] -- --- !-- NOTE : If you set isVirtualWebappRelative to 1 (true), -- !--you probably want to set crossContext=true on the -- !--context that contains the server-side include files -- !--because otherwise the default security will prevent -- !--access to other contexts. The file to change is -- !-- server.xml. -- 181,207c184,204 servlet servlet-namessi/servlet-name servlet-class org.apache.catalina.servlets.SsiInvokerServlet /servlet-class init-param param-namebuffered/param-name param-value1/param-value /init-param init-param param-namedebug/param-name param-value0/param-value /init-param init-param param-nameexpires/param-name param-value666/param-value /init-param init-param param-nameisVirtualWebappRelative/param-name param-value0/param-value /init-param init-param param-nameignoreUnsupportedDirective/param-name param-value1/param-value /init-param load-on-startup4/load-on-startup /servlet --- servlet servlet-namessi/servlet-name servlet-classorg.apache.catalina.servlets.SSIServlet/servlet-class init-param param-namebuffered
Re: [PATCH] Re: SSI Servlet has big problems
Dan Sandberg wrote: Yes, let's merge them together. How do I get to the code that you fixed? Were the test cases in CVS? It's all in CVS. If you checkout the source code from some time in December you should get it all back in util and util/ssi. It looks like my last check-in was on November 29th or so. I too made some pretty significant changes. It looks like my final test.xml never made it in, but I'm attaching it here. (Only the SSI parts are relevant of course.) All of the golden files look like they're still there. I'd say lets get all the test cases setup, and see where my code fails your tests. Then we can use your code wherever functionality is missing. The motivation for my original changes was to fix the nesting of .shtml files (ie: a .shtml file including another .shtml file) and to add support for set, variable substitution, conditionals, etc.. When I looked at the original version and saw it was such a mess, I did pertty much a complete rewrite. Some of my changes are similar to yours, but I got rid of classes like SsiMediator and such. All of this included fixing how variables were kept for includes and such, as well as parsing fixes and the addition of some new commands. It's all pretty significant and may not naturally fit some of your refactoring. To be honest, it might be easier to redo your changes against my stuff than it would be to graft my stuff onto yours. Even though I know that's probably a real pain in the a**. In it's current state, I think the current fixed version has much less functionality than the previous fixed version. Hopefully we can work something out. I thought I had checked out the head revision. Did I make a mistake with the cvs check out command? Must have. The fact that you even have an SsiMediator means you were changing an older version. Unfortunately, Bill didn't notice this when he committed your stuff and probably just whole-sale nuked the older files. Don't feel too bad about that, though. My original rewrite did something similar. Only in my case, it was only a small bug fix that was reverted. Still a little disconcerting from my point of view. Probably my own fault for taking a two-month break from the lists. And I had no idea I could have parlayed those patches into committer access. :) -Paul -Dan Paul Speed wrote: (Resending from my older address in hopes that it will help avoid some confusion.) Hmmm... This is what I get for ignoring the list for a while. ;) Note: I completely rewrote the SSI support in 4.x HEAD and had Bip apply the patches (Amy also did some patching) for exactly the same reasons you originally mention. I did this around Oct/Nov 2001. On most of the 4.0 bug reports for SSI (which I agree was a bad implementation on that branch) I commented that my changes should probably have been back-ported from head. I even had test cases for all of the SSI commands, including the conditionals which I added support for. My only guess is that you were looking at an older version when finding the problem. My rewrite solved all of these problems and was completely compatible with all mod_include commands except for the regex stuff. Of course, now it seems that my version has been completely blown away. Which is unfortunate since that means we lose conditionals... and possibly some of the more esoteric nesting behavior that I copied from Apache (I haven't tested this yet.) It's too bad that SSI on head was blown away for changes to an older version. Any chance we can nicely merge the two good versions into one more good version? -Paul Speed Dan Sandberg wrote: Hi everyone. Here are more changes to the SSI code. I have a test case ( comparing SSI behavior to Apache by using .shtml files in different tomcat webapps / apache directories ) which I have not included because I'm not sure where to put manual test cases like this. If there is an apprioriate place for these kinds of things, please let me know. I also have not yet updated package.html in the o.a.c.ssi directory. I will do this when I come back from a weekend trip. Here are the instructions for installing the new code, using the jakarta-tomcat-4.0 dir as the base dir. delete files in ( and dir ) : catalina/src/share/org/apache/catalina/util/ssi delete file: catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java unjar the jar -this puts SSIServlet.java into catalina/src/share/org/apache/catalina/servlets -this puts the rest of the files in catalina/src/share/org/apache/catalina/ssi Since the name of the SSI servlet class changes, and since I added some notes to it, patch web.xml according to the included patch. Since I'm planning on maintaining this for a while, commit access might be a good idea, as it makes things easier for everyone. Thanks have a great weekend! -Dan Index: web.xml
Re: [PATCH] Re: SSI Servlet has big problems
(resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Don't know... have you tried an absolute date or is 4 months ago just an example for the list's benefit. Any date in feb/april should be sufficiently late enough. Hope it works, -Paul Dan Sandberg wrote: I'm trying to checkout an old version of tomcat with the following command: [dan@oogie tmp]$ cvs co -D 4 months ago jakarta-tomcat-4.0 And I'm getting the following error: Core dumped; preserving /tmp/cvs-serv41751 on server. CVS locks may need cleaning up. My version is (on Linux): [dan@oogie tmp]$ cvs --version Concurrent Versions System (CVS) 1.11.1p1 (client/server) I tried the same thing on Solaris, and had the same problem. Any idea? Am I doing something stupid? -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: SSI Servlet has big problems
(resending from my progeeks.com address to avoid being filtered/delayed by moderation.) Dan Sandberg wrote: Ugh this is painful. I'll checkout your stuff within the next few days. If the architecture looks good and does have significantly greater functionality I will merge my changes into your code. I also fixed the included variable problem and the nested include problems. The conditional stuff was the only thing I thought I was missing. Hmmm... maybe it isn't as bad as I thought? I don't know. I know there were some parsing problems that kept variable substituation from working correctly. I'm curious: How could I have checked out an older version accidently? Wouldn't I have had to explicitly specify a date or tag or something? Well, if you started working from a tarball of the source, that might have done it. I think that's what happened in my case originally. I can't remember exactly, but the tarball I had might have even had CVS directories in it with sticky tags already set... ie: keeping me from easily getting the latest without checking out the whole source tree from scratch. ... This is all quite depressing ... Indeed. Thanks for being so gracious about all of this. I really felt quite sick when I saw what I missed. That'll teach me to ignore my inbox. :) -Paul -Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where can I find the spec to implement SSI on Jakarta Tomcat 4.0?
Amy Roh wrote: Mike Jette wrote: Where can I find the spec to implement Server-Side Include (SSI) on Jakarta Tomcat 4.0? Note: I'm pretty sure that Catalina 4.0.x only has a minimal support for SSI. I rewrote it all to include everything that Apache mod_include does (except the some perl or regex stuff, don't quite remember) but I'm pretty sure those changes only exist in the HEAD branch, ie: 4.x. As far as I know, that stuff was never back-ported and so is only available when using a nightly build or building from source. Also note: The older SSI can only serve one request at a time or it will possibly mix output to the different clients. This was actually my original reasons for fixing the SSI servlet in Catalina since it messes up nested includes too. The other reason was that I needed conditionals. -Paul Speed There isn't an actual spec for SSI feature for Tomcat 4.0. It follows the NCSA SSI rules same as the Apache documentation. You need to uncomment SSI Servlet in web.xml. And to use the SSI servlet, you also need to rename the $CATALINA_HOME/server/lib/servlets-ssi.renametojar file to $CATALINA_HOME/server/lib/servlets-ssi.jar Amy If you can point me at a link I would really appreciate your help. Is it that same as the Apache documentation? Thanks you. -- Michael E. Jette Technology Partners, Inc. 636-519-1221 ext. 104 1-877-636-1331 ext. 104 (toll free) www.tech-partners.com -- 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: [Daemon] New commons component
Comments below...
Pier Fumagalli wrote:
Patrick Luby [EMAIL PROTECTED] wrote:
Maybe I should clarify what I am trying to do. I am trying to enable the use
of setuid() within the existing Tomcat startup process (i.e. shell scripts). I
definitely like your native launcher and the more I look at it, the more I
like its sophisticated function. I just want to make the setuid() call
available even if I haven't startup Tomcat using your native launcher. The way
to do that is to use the Java-JNI method of creating a shared library that
contains a function with a name that matches a demangled version of a public
native Java method. Then, when Tomcat is started via a script (as it does
now), the StandardServer class can do the following:
- Invoke System.loadLibrary()
- Bind all of the ports (if you are root, you can bind to ports = 1024)
- If we are root, invoke a public native method that Java maps to the C
function contained in the shared library. The C function would contain
the setuid() C call to change the Java process to a non-root user
Hmm... I don't like it, but now I got what you're trying to do...
The above method effectively does the same thing as your native launcher. The
only difference is that I thought it might be a may to get your setuid code
into the standard Tomcat installations
The only code working is within Tomcat, and it's there already... Look at
the API changes in the Connector I pointed out yesterday, and at the
different Embedded solutions (like the one Remy did for Win32 services)...
The java code is there, the entry points are all there... All we need is a
JNI wrapper/invocator which loads the VM, calls initialize(), sets the
UID/GID, calls(start), wait for a signal, calls stop()...
much sooner since my proposed approach
is compatible with the existing Tomcat configuration and startup.
Given that I don't even have time to blow my nose ATM, I won't argue on
implementation, but just comment on the idea... Calling setuid() from Java
is crap (design wise), because it's against all design principles Java is
based on... It's not portable, and there is already a much better
alternative that is completely platform independant... Someone just needs to
make it work (I'd give a one-week time to a guy like you to make it run :)
I think the only changes to support my proposed approach in your native code
are the following:
- Add a public static native method in DaemonLoader.java
- Create a DaemonLoader.h file using javah
- Implement the setuid() calls for the function defined in DaemonLoader.h
in DaemonLoader.c. Specifically, I could just move the child process' code
in the checkuser function here so that there is not duplication of code.
- Add compiling and linking of DaemonLoader.c into a shared library that the
Java System.loadLibrary() call can handle.
- Add calling of this public static native method from Tomcat's
StandardService.initialize() method (i.e. after all ports have been bound).
Also, what I don't like is the pollution of Java code with calls to specific
methods which are System dependant. It's true you can implement a void
setuid on platforms where it's not supported, but design wide is crap
(IMO).
Also, if you need to do some callbacks from Java into our native C code, the
easiest thing is to register those right after invoking CreateJavaVM in JNI
(and it works), rather than relying on an external library...
I was thinking that once we have the above method implemented, we could try
replacing the existing scripts with the native launchers. At that point, the
System.loadLibrary() call in Tomcat could be removed since the native launcher
could register the JNI C function that the public native method maps to.
What do you think of the above approach?
As I said, I'm more on the approach I outlined several times here and on the
JSR-096 mailing list my preferred approach to the problem is to create a
wrapper around the Java Virtual Machine and an API defining the lifecycle of
a Daemon process...
Not in many details, the API I would love to see is (at the end) something
like:
public interface Daemon extends Runnable {
public void init(...);
public void destroy();
}
Init() can be called as root if the process is started as root, otherwise,
it gets called at whoever, after init() returns cleanly, the main thread
starts sleeping and waiting for signals, a new thread is created and this
calls the run() method in Daemon (extends runnable!)...
I imagine it's at some point in there that the UID can get changed
to some non-root value?
One benefit to Pier's approach that I haven't seen mentioned is of
particular concern to paranoid sysadmins (redundant?). If I run
tomcat with a security manager I should be able to turn off native
code completely in the policy file. Then I only need to audit the
source code for the launcher to verify that my
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpResponseStream.java
Sorry to comment, but I see this one again and again on all kinds of
projects. :)
-if (servletRequest.getMethod().equals(HEAD))
+if ((servletRequest.getMethod() != null)
+ (servletRequest.getMethod().equals(HEAD))) {
Almost always better to go ahead and invert the equals:
if (HEAD.equals(servletRequest.getMethod()))
A simpler idiom to remember and will save the null check. Just a
friendly tip.
-Paul
[EMAIL PROTECTED] wrote:
remm02/02/20 11:24:38
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpResponseStream.java
Log:
- Fix a NPE which could happen with an invalid request.
Revision ChangesPath
1.12 +7 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java
Index: HttpResponseStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- HttpResponseStream.java 27 Nov 2001 16:22:47 - 1.11
+++ HttpResponseStream.java 20 Feb 2002 19:24:38 - 1.12
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
1.11 2001/11/27 16:22:47 remm Exp $
- * $Revision: 1.11 $
- * $Date: 2001/11/27 16:22:47 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java,v
1.12 2002/02/20 19:24:38 remm Exp $
+ * $Revision: 1.12 $
+ * $Date: 2002/02/20 19:24:38 $
*
*
*
@@ -250,10 +250,12 @@
protected void checkHead(HttpResponseImpl response) {
HttpServletRequest servletRequest =
(HttpServletRequest) response.getRequest();
-if (servletRequest.getMethod().equals(HEAD))
+if ((servletRequest.getMethod() != null)
+ (servletRequest.getMethod().equals(HEAD))) {
writeContent = false;
-else
+} else {
writeContent = true;
+}
}
--
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: new photos from my party!
Heh, I bet a whole bunch of people on this list just double checked that they don't have the virus, though. I know I did even though I don't use Outlook. Seeing your own e-mail address in the From: line is a little disconcerting. -Paul jean-frederic clere wrote: Bernd Koecke wrote: Hi all, I don't know why this Mail comes to the list. I'm working with a Linux-System and Mozilla as Mail-Reader. [EMAIL PROTECTED] wrote: I can't see how my system could send this mail. Everyone has received it like that for example I have: [EMAIL PROTECTED] Is it possible that this mail is in the inbound-foulder of someone else? But it is the autogenerated mail response for my last subscribtion after X-Mas vacation. I'm sorry, if I be the origin of this mails. But I don't know how to stop it. Could someone send me in the right direction? Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Default classes loaded by Tocmat
Kevin Jones wrote: Why not implement your own JSP base class that imports the classes/packages you need and have all your pages extend that new class. This would also be portable across implementations! It would also not work. import statements are only for the compiler. They have nothing to do with the compiled classes. The subclass must define its own imports if it wants to reference the classes in source. -Paul Kevin Jones Developmentor www.develop.com -Original Message- From: Anand Bashyam Narasimham [mailto:[EMAIL PROTECTED]] Sent: 26 December 2001 21:35 To: 'Tomcat Developers List' Subject: RE: Default classes loaded by Tocmat I agree and that's why I still stick to Tomcat :) -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 26, 2001 1:34 PM To: Tomcat Developers List Subject: RE: Default classes loaded by Tocmat On Wed, 26 Dec 2001, Anand Bashyam Narasimham wrote: Date: Wed, 26 Dec 2001 12:31:26 -0800 From: Anand Bashyam Narasimham [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] Subject: RE: Default classes loaded by Tocmat Craig, I know Tomcat has always been a standards compliant implementation. But will it be possible say for developers to have extensions where instead of writing the import statements in a whole lot of JSPs we make sure the Class loader loads this as a extension to the list you've mentioned using some config file read at startup. I do agree that this make it a non-portable JSP, going against the spirit of Java and J2EE but today everything written on J2EE though Java is almost 60% not portable onto a different implementation :) Can this be done? Sure it can ... by you, modifying the source code yourself and supporting it yourself. I'm not going to help you, however, do something this crazy. It's one thing when vendors lock you in with non-portable features. It's a different, and much sadder thing, to see people willing to paint themselves into a corner like this :-(. Anand Craig -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:tomcat-dev- [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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
[EMAIL PROTECTED] wrote: On Thu, 20 Dec 2001, Kevin Seguin wrote: perhaps now is the time to do some rethinking of where the connectors for each serlvet container live. today, in j-t-c, there is the framework (for lack of a better word) for connectors plus the individual connectors or adapters for tomcat 3 and tomcat 4. personally, i think it would be better to have the individual connectors/adapters live with the servlet container itself. i.e. put the ajp13 connector for tomcat 4 in the jakarta-tomcat-4.0 source tree. this way, j-t-c can build without having dependencies on any servlet containers, and servlet containers that want to provide connectors that make use of j-t-c can (optionally) depend on j-t-c. My thinking ( for 4.1/3.3 ) was to have j-t-c built as a 'standalone module', a trusted/priviledged webapp that can be deployed and is self-contained. Keeping all container adapters in j-t-c has the extra benefit that we can share more code among them. It still feels wierd to me. Imagine if JNDI did things this way... we'd have to have every provider installed just to build it. :) I think if the layer of abstraction is at the right point you can get a compromise between code reuse and modularity. Otherwise, since the container adapters are in a different module than the containers themselves, there are always going to be cases where container improvements break the connector build. This is because they are tagged differently, etc.. Right now it seems to be structured that j-t-c is the application and the containers are its libraries. It seems like it should really be the other way around. But that's just my non-committer $0.02. And I run Tomcat stand-alone anyway... the engineer in me just had to say something. :) And the build changes I'm trying to make should simplify building for all or just individual containers. For the current release - I don't think we should move the code. For jk2 - I also think we should wait until it's in a more concrete shape. So are you saying that the dependencies should be restructured as discussed above, but just not yet? -Paul 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]
Re: org.apache.tomcat.util.net package in tomcat 3.x
Kevin Seguin wrote: Catch me if I'm wrong, but currently j-t-c is dependent on tomcat code, right? I make this statement without having actually looked at the code for the connectors. I'm going by recent discussions about how an API change in Catalina broke the build for a connector. some very small parts of jtc are dependent on tomcat. these are the adapters/connectors for tomcat. much of what is in jtc is totally tomcat-agnostic, and is buildable without tomcat. personally, i believe the adapters/connectors for each servlet container (tomcat3, tomcat4, perhaps jetty someday) should exist in the container module, and the container modules should depend on jtc, not the other way around. Yeah, that's what I was getting at. -Paul just my $0.02. -kevin. -- 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: [SSI] initial environment?
Brian Zhou wrote:
Hi tomcat-developers,
Is there a prefered way to set the initial env for an SSI page? I'm working
on a simple template servlet using SSI to allow something like:
!--#include virtual=${header}--
!--#include virtual=${body}--
!--#include virtual=${footer}--
Most of the support are there, but how does one set the initial env
programatically from a servlet? I know probably I can add a
tomcat.ssi.environment SsiEnvironment instance as attribute of the
HttpServletRequest, but it seems to involve the whole catalina.jar and
servlets-ssi.jar (and maybe more) being copied into
servletContext/WEB-INF/lib. Is it possible we leave a light-weight,
loosly-coupled hook for this purpose? I give an example below just using
Hashtable, of course we can change the attribute name.
JSP and taglib can achieve the same thing, but I just like the
non-invasiveness of SSI better - everything still in valid HTML.
That's an interesting idea. I hadn't thought of that when I wrote
that stuff. The problem with using SsiEnvironment directly is, as
you noticed, that it is in the catalina class loader and relies on
at least one other catalina.jar class. (This was true even before
my SsiEnvironment changes.)
Your code snippet below works, of course. I'm not a committer, just
an interested party that recently refactored most of the SSI stuff as
a simple contributor ;) ... so I can't actually do anything about any
suggestions along these lines. The only hesitation that I think a
committer would have is that your changes are non-standard. I'm
pretty sure that there is no standard way to set SSI variables from
a servlet... and certainly no pre-defined way in the SSI support in
catalina. My pretty sure also comes from the experience of looking
through the apache module to make sure the tomcat version is as
compatable as possible.
The reason I enhanced the SSI support in the first place is because
I frequently do something similar myself. However, in my case,
my pages contain the body and just include the header and footer.
That way I still have unique URLs for my content... they just pull
in the standard parts from other files. I don't know if that will
work in your case, though.
Otherwise, your custom mods are probably the only way to solve your
needs.
-Paul
Thanks,
-Brian
diff -r1.2 SsiEnvironment.java
69d68
import java.util.Date;
72a72,73
import java.util.Date;
import java.util.Enumeration;
257a259,267
Hashtable initialEnv = (Hashtable)
request.getAttribute(initial.env);
if (initialEnv != null) {
Enumeration e = initialEnv.keys();
while (e.hasMoreElements()) {
String key = (String) e.nextElement();
this.setVariable(key, (String) initialEnv.get(key));
}
}
--
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]
servlets-ssi.renametojar
Hello, I'm currently looking into the security issues pertaining to enabling this by default. I followed the conversation for why it is the way it is, but now that I'm actually in the guts of the thing, I don't think I fully understand. The issue as I remember it is that the SsiExec class in servlets-ssi.jar could be exploited even if SSI support wasn't enabled in the web.xml file. The part I'm fuzzy on is how this can be true. Since servlets-ssi.jar is loaded into the server class loader (server/lib) it seems to me that it would be impossible for a rogue webapp to access any classes in this jar. In any case, my solution should protect from these kinds of attacks also, I'm just not sure they're possible. I'll be submitting a patch shortly that should allow SSI support to be enabled by default but would require a specific configuration change to get the exec directive to work. -Paul Speed P.S.: I'd be curious to know of anyone actually using the exec directive. Looking at the code, I'm not sure I see how it works for non-CGI stuff. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] SSI Security
As promissed...
I've attached my patches to allow the exec directive to be enabled
or disabled (disabled by default). The extra safety check I've built
in isn't really necessary, but it causes no harm and may prevent some
accidental foot-shootings in the future.
ssi-exec.patch is a diff -u from the catalina/src directory. (We'll
see if the attachment actually works to the list since I've had
problems with that before.)
Left up to discussion is the vulnerability of the jar file itself.
I contend that since the jar is in the server/lib class loader that
it is perfectly safe. Indeed, when I played with moving it into
shared it resulted in broken dependencies with at least one class
in server/lib.
If it is not safe then it brings up a larger issue since all
server/lib class have AllPermission and can therefore do whatever
they want. If these classes are exploitable by webapps then it seems
to me that security should be set more fine grained (including not
allowing file execute for any file). Otherwise, there's always risk
that some backdoor will be left open.
-Paul
Index: conf/web.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v
retrieving revision 1.31
diff -u -r1.31 web.xml
--- conf/web.xml2001/11/21 17:36:52 1.31
+++ conf/web.xml2001/11/29 08:05:04
@@ -165,6 +165,12 @@
!-- be ignored and no errors shown?--
!-- (0=false, 1=true) [1] --
!-- --
+ !-- allowExecDirective --
+ !-- Should the exec directive be allowed in SSI--
+ !-- pages? When false, exec will be treated like --
+ !-- an unknown command.--
+ !-- (0=false, 1=true) [0] --
+ !-- --
!-- IMPORTANT: To use the SSI servlet, you also need to rename the --
!--$CATALINA_HOME/server/lib/servlets-ssi.renametojar file --
!--to $CATALINA_HOME/server/lib/servlets-ssi.jar --
@@ -194,6 +200,10 @@
init-param
param-nameignoreUnsupportedDirective/param-name
param-value1/param-value
+/init-param
+init-param
+ param-nameallowExecDirective/param-name
+ param-value0/param-value
/init-param
load-on-startup4/load-on-startup
/servlet
Index: share/org/apache/catalina/servlets/SsiInvokerServlet.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
retrieving revision 1.14
diff -u -r1.14 SsiInvokerServlet.java
--- share/org/apache/catalina/servlets/SsiInvokerServlet.java 2001/11/29 03:50:48
1.14
+++ share/org/apache/catalina/servlets/SsiInvokerServlet.java 2001/11/29 08:05:05
@@ -161,6 +161,13 @@
}
try {
+value = getServletConfig().getInitParameter(allowExecDirective);
+
+ssiDispatcher.setAllowExecDirective((Integer.parseInt(value)0)?true:false);
+} catch (Throwable t) {
+;
+}
+
+try {
value = getServletConfig().getInitParameter(expires);
expires = Long.valueOf(value);
} catch (NumberFormatException e) {
Index: share/org/apache/catalina/util/ssi/SsiDispatcher.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/ssi/SsiDispatcher.java,v
retrieving revision 1.2
diff -u -r1.2 SsiDispatcher.java
--- share/org/apache/catalina/util/ssi/SsiDispatcher.java 2001/11/29 03:41:26
1.2
+++ share/org/apache/catalina/util/ssi/SsiDispatcher.java 2001/11/29 08:05:06
@@ -76,7 +76,7 @@
* @version $Revision: 1.2 $, $Date: 2001/11/29 03:41:26 $
* @authorPaul Speed
*/
-public class SsiDispatcher {
+public final class SsiDispatcher {
/**
* Determines how to treate unknown command references.
@@ -84,6 +84,11 @@
private boolean ignoreUnsupportedDirective = true;
/**
+ * True if the exec command is allowed.
+ */
+private boolean allowExec = false;
+
+/**
* Contains the SSI command instances. This is shared
* across all dispatcher instances.
*/
@@ -99,7 +104,6 @@
ssiCommands.put(echo, new SsiEcho());
ssiCommands.put(fsize, new SsiFsize());
ssiCommands.put(flastmod, new SsiFlastmod());
-ssiCommands.put(exec, new SsiExec());
ssiCommands.put(set, new SsiSet());
SsiConditional cond = new
Re: servlets-ssi.renametojar
Glenn Nielsen wrote: I am pleased to see the interest in security issues. But when developing solutions for security issues we need to remember that Tomcat4 can use the Java SecurityManager. And in almost all cases the security needed can be achieved by using catalina.policy. We should leverarge the Java SecurityManager as much as possible to solve these types of security issues rather than writing and relying on our own code to enforce security. The issue you are addressing Paul can also be addressed by my PROPOSAL a week ago. If Tomcat is running with the Java SecurityManager the SSI servlet can't perform an exec unless it has been granted permission to do so. Yes. I like it. I hadn't thought about creating yet another class area to provide finer grain security for just the catalina servlets. I'll have to search for your original proposal and take a look. More below... -- 1. Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes. This is where global servlets provided with Tomcat 4 can be installed. 2. Move the following jar files into $CATALINA_HOME/servlets/lib servlets-cgi.renametojar servlets-common.jar servlets-default.jar servlets-invoker.jar servlets-manager.jar servlets-snoop.jar servlets-ssi.jar servlets-webdav.jar 3. Update the class loader creation in Bootstrap.java for the catalina loader to look for jar files and classes in $CATALINA_HOME/servlets in addition to $CATALINA_HOME/server. 4. Update the default catalina.policy so that it provides explicit permissions for each jar file in $CATALINA_HOME/servlets/lib. 5. Update the documentation regarding the above changes. Please vote +1 so I can implement the above changes. -- I'm not a committer but I'm willing to help with this. So that's my +1 for what it's worth. It is time to consider making use of the Java SecurityManager the default startup option for Tomcat, or even require that Tomcat be run with the Java SecurityManager. I agree. I had heard horror stories about getting tomcat to run with the security manager, but I found it very easy. It took me a bit to figure out that the server class loader runs with AllPermission and that's why Runtime.exec() is allowed in these servlets. I think that even with moving the servlets to their own area that the server policy should probably be finer grained. AllPermission is convenient but there are clearly a few things that that even these classes shouldn't be allowed to do. (Runtime.exec for example) Having the server area explicitly spell out its security needs will also make fine-tuning that security easier for the more paranoid sys admins. All that being said, my patches for disabling the exec directive might still be useful. Since it simply removes the directive from consideration it causes it to be treated as an unknown command rather than a security error. Currently, unknown commands can be ignored with the correct option. In an ideal world, all of the directives would be configurable but that seemed like overkill. Anyway, I'm going to try and setup your proposal here locally and see if I find any problems. -Paul Regards, Glenn Paul Speed wrote: Hello, I'm currently looking into the security issues pertaining to enabling this by default. I followed the conversation for why it is the way it is, but now that I'm actually in the guts of the thing, I don't think I fully understand. The issue as I remember it is that the SsiExec class in servlets-ssi.jar could be exploited even if SSI support wasn't enabled in the web.xml file. The part I'm fuzzy on is how this can be true. Since servlets-ssi.jar is loaded into the server class loader (server/lib) it seems to me that it would be impossible for a rogue webapp to access any classes in this jar. In any case, my solution should protect from these kinds of attacks also, I'm just not sure they're possible. I'll be submitting a patch shortly that should allow SSI support to be enabled by default but would require a specific configuration change to get the exec directive to work. -Paul Speed P.S.: I'd be curious to know of anyone actually using the exec directive. Looking at the code, I'm not sure I see how it works for non-CGI stuff. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe
Re: servlets-ssi.renametojar
Glenn Nielsen wrote: [snip] Glad to hear you had success using Tomcat with the Java SecurityManager. Where I work we have several different installs of Tomcat. All of them use a much more restrictive policy file than the default catalina.policy. At one point the Tomcat 4 Security Manager docs included an example of a more restrictive policy than the default catalina.policy that Tomcat 4 is distributed with. If I have time, I will update those docs for the Tomcat 4.0.2 release. And perhaps add an example catalina.policy to the distribution which is more restrictive. Hmmm, now that the framework is there for the admin web application, perhaps an easier to understand interface could be added to if for configuring the catalina.policy file. I may have to take a look at these examples. Trying to whittle down AllPermission by guess work is a daunting task to say the least. ;) I'll RTFM before I complain too loudly. :) All that being said, my patches for disabling the exec directive might still be useful. Since it simply removes the directive from consideration it causes it to be treated as an unknown command rather than a security error. Currently, unknown commands can be ignored with the correct option. In an ideal world, all of the directives would be configurable but that seemed like overkill. Yes, that might be useful. I just don't want to see Tomcat 4 littered with alot of 'security' code when security can be enforced using the Java SecurityManager and a policy file. I whole-heartedly agree with that. -Paul Anyway, I'm going to try and setup your proposal here locally and see if I find any problems. Let me know how it works out. Thanks, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servlets-ssi.renametojar
Hello,
In my playing around with security, I've been attempting to break-out
the AllPermission for the $(catalina.home}/server classes into
something more granular to allow more refined tweaking. Here's what I
have so far:
grant codeBase file:${catalina.home}/server/- {
permission java.lang.RuntimePermission *;
permission java.io.FilePermission ALL FILES,
read,write,delete;
permission java.util.PropertyPermission *, read,write;
permission java.security.SecurityPermission *;
permission java.net.SocketPermission *:0-,
accept,connect,listen,resolve;
permission java.net.NetPermission *;
permission java.io.SerializablePermission *;
permission org.apache.naming.JndiPermission *;
};
I've already removed the execute from the FilePermission and I've
left out the reflection permission since that's a really really ugly
one. Some of the above are probably way too broad... but certainly
no broader than AllPermission. I decided to start from the other
end of the spectrum and work backwards. With the above, I can still
run my own stuff and the tester stuff.
Incidentally, the tester webapp fails to initialize when the security
manager is enabled. Since it uses PropertyEditorManager in one of
its files, it requires PropertyPermission *, read,write in order
to run. I'm still trying to figure out how to enabled this just for
the tester app (I have it working if I stick it in the general grant
section). The docs in catalina.policy don't seem to be helping much.
The other curious thing about this particular error is that it doesn't
show up as an access failure when using the debugging built into the
security manager.
-Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] SSI support
Hello, I'm posting my SSI patches again since the CVS versions have changed since I last posted them. This latest version has Amy Roh's most recent changes merged into it. The description is the same as in the quoted e-mail. I'm going ahead and including all.zip which contains the various patches in case the nice committer that gets to this doesn't feel like hitting the web link. :) Here is the description of what all.zip contains (also from the web page linked below): SsiInvokerServlet.diff diff -u output for the org.apache.catalina.servlets.SsiInvokerServlet. This patch should be independent of the others since it just fixes some SSI directive parsing issues. new_classes.zip 4 new .java files for the org.apache.catalina.util.ssi package. Note: I did not add apache headers to these files since I didn't think it was appropriate for a non-committer to do so. util_ssi.diff The diff -u output for many of the other files in the org.apache.catalina.util.ssi package. tester_web.zip New files for the tester/web directory. Includes files for the tester/web/golden directory as well... all relative to tester/web. tester.diff diff -u output for src/bin/tester.xml. It adds the appropriate directives for the tests added from tester_web.zip. My interest in seeing these changes committed is two-fold: 1) I'd like to know if there are any problems that may require my help to resolve. 2) I have some additional changes I'd like to propose at some point but I don't want to make my patch set any larger than it already is. :) Specifically, I want to lock down the exec directive so that SSI can be safely/securely deployed by default. If someone looks at this stuff and finds something wrong, then please let me know. Thanks. -Paul Speed Paul Speed wrote: Hello, I realize Bip is away, but I thought I'd post these anyway before I forget about them. Since I've had problems with multiple attachments I went ahead and stuck the files on my web site at: http://www.progeeks.com/pspeed/tomcat/SSIPatches.html Each file has a description of what it contains and where it should go. If a committer chooses to apply them and has problems then let me know. Here is the description of the changes from the above-linked page: What I did... The changes to SsiInvokerServlet should be independent of the other changes. Really, I just improved parsing support to handle escaped characters, etc. and be more error-compatible with Apache. The other SSI commands were modified to be more compatible with Apache SSI. Specifically, I've verified that the supported tags should work the same as mod_include in Apache 1.3.22. At least they support the same options. The tags were also enhanced to fit with the new conditional tags. I also added the implementation of the conditional tags: if, elif, else, and endif. This includes an expression parser. It's been a while since I've written a parser and I tried to do it with a slant on understandability. There's probably room for improvement, but it works the same as Apache on all of the tests I've tried... and it passed all of the new tester pages which generate identical output to Apache 1.3.22. So after these patches, the only tags that are missing that mod_include has are printenv and perl (which is conditionally included anyway). Also, the encoding parameter on echo is silently ignored right now. Thanks, -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] all.zip Description: Zip compressed data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Distributed Session Management
The only problem with including the tests right in the same package is that they can be hard to remove for a test-free distribution. Also, since they are in the same package, they have access to some non-public methods and properties... this can make them a security risk in some cases (especially since they can't be easily removed). When opting not to build a separate hierarchy for test classes, we always created a test sub-package. I can present numerous reasons why it is better to use a separate hierarchy, but I'm not sure I'd change anyone's mind. :) -Paul Tom Drake wrote: Mika: - Original Message - From: Mika Goeckel [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Tom Drake [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 3:31 AM Subject: Re: Distributed Session Management | Tom, | | from my (personal?!) philosophy, tests should be with the tested targets. My | experience tells me that tests get out of focus if they are in a separate | tree. I agree, I like to place them in the same package as the code being tested. In other projects, I've used a naming convention to distiguish between Test classes and other classes (e.g. test classes are named Test?.java) | Now when you are going to start hacking, is your approach creating use | cases, sequence diagrams etc. before, or something like class responsibility | cards? Usually, I use a combination of things. In my mind the electronic equivalent of class responsibility cards are java interface definitions or sparse classes with some javadoc. The initial message that I sent out that started this thread had a couple of java interfaces. I'll be sending some more around. I'll may also send some class diagrams, and sequence or collaboration diagrams. Tom P.S. | | M. | | - Original Message - | From: Tom Drake [EMAIL PROTECTED] | To: Tomcat Dev List [EMAIL PROTECTED] | Sent: Wednesday, November 14, 2001 8:39 PM | Subject: Distributed Session Management | | | Tomcat Developers: | | I'm going to try to synthesize the results of yesterdays | discussion on Distributed Session Management into some | working code. From what I can tell, there will be some | changes and new objects in the org.apache.session | package, and possibly some new objects in the | org.apache.cluster package. | | I should have something to share in the next couple of | days. I'll be creating JUnit tests as I write this code. Is there | a standard place to put JUnit tests, or can I simply place | them in the same package as the classes being tested? | | Regards, | | Tom Drake | Email: [EMAIL PROTECTED] | | | -- | 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] | | | -- 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: Distributed Session Management
Craig R. McClanahan wrote: On Thu, 15 Nov 2001, Paul Speed wrote: Date: Thu, 15 Nov 2001 14:40:35 -0500 From: Paul Speed [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Distributed Session Management The only problem with including the tests right in the same package is that they can be hard to remove for a test-free distribution. Also, since they are in the same package, they have access to some non-public methods and properties... this can make them a security risk in some cases (especially since they can't be easily removed). When opting not to build a separate hierarchy for test classes, we always created a test sub-package. I can present numerous reasons why it is better to use a separate hierarchy, but I'm not sure I'd change anyone's mind. :) There's actually a solution that works for both camps: parallel source directory hierarchies. src/java/org/apache/foo -- Contains the implementation src/test/org/apache/foo -- Contains the tests Right, that's my preferred approach as well. The other nice thing about a separate source hierarchy is that if you decide to one day change testing methodologies, your real source tree is still pure. Just create a src/junit/org/apache/foo or src/supertest/org/apache/foo as needed. -Paul Then, just set up your build scripts to only compile the tests if you need them -- a build to create a distribution will omit them. Yet, the test classes will still be in the same Java package, so you can test package protected methods without having to modify the implementation classes. The existing JUnit tests in jakarta-tomcat-4.0 (plus bunches of other Jakarta projects like those in Commons) follow this style. -Paul Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Recycle objects in TomCat, Performance gain?
There are several reasons to use pooling, including (but not limited to): -Eliminating object creation time -Managing expensive resources (really same as first) -Keeping memory usage constant (popular in embedded environments) -Reducing garbage collection Only the last one is addressed by the quotes below. And is especially visible in cases where a program may create, for example, 5000 Rectangle objects and then manage the pool as needed. The current GCs will be much better at managing these objects than a pool would. Tomcat benefits from all of the above reasons, but from a performance perspective, probably mostly from the first two. (Costin's analysis in the other response seems to bear proof of this.) -Paul Samuel Cheung wrote: Hi, In TomCat's source code, I notice it recycles objects (e.g. RequestBase, StandardSession). But in Sun's documentation, with HotSpot Virtual machine, pooling objects will hinder performance (see below). Could someone please tell me are there advantages of using object pooling in TomCat? Thank you. Sam From Sun's Web Page. http://java.sun.com/docs/hotspot/PerformanceFAQ.html#15 Should I pool objects to help GC? Should I call System.gc() periodically? Should I warm up my loops first so that Hotspot will compile them? The answer to all of these is No! Pooling objects will cause them to live longer than necessary. The garbage collection methods will be much more efficient if you let it do the memory management. We strongly advise taking out object pools. Don't call System.gc(), HotSpot will make the determination of when its appropriate and will generally do a much better job. If you are having problems with the pause times for garbage collection or it taking too long, then see the pause time question above. Warming up loops for HotSpot is not necessary. HotSpot now contains On Stack Replacement technology which will compile a running (interpreted) method and replace it while it is still running in a loop. No need to waste your applications time warming up seemingly infinite (or very long running) loops in order to get better application performance. See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine. -- 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: Tomcat: Distributed Session Management revisited
Tom Drake wrote: - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED]; Tom Drake [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 1:25 PM Subject: Re: Tomcat: Distributed Session Management revisited ... stuff deleted ... | | It would be possible to do this for the HttpSession methods | | themselves (the container would know what's going on), but what do you do | | about session attributes? | | | | HttpSession session = request.getSession(); | | MyObject mo = (MyObject) session.getAttribute(foo); | | mo.setName(bar); | | I believe that, in this case, it is incumbent upon the application to call | | session.setAttribute(foo, mo); | | | This violates the principle that the application programming model should | not change, but it's certainly feasible to say if you want load balancing | to work on this container, you have to call HttpSession.setAttribute() | whenever you modify an attribute's properties. | | By itself, though, this doesn't provide any support for locking against | simultaneous updates (i.e. what you do in synchronized blocks in a | single VM). | | It's a little funny funny ... by the time we invent API to solve all these | problems, you've just defined a pretty fair chunk of the functionality of | EJBs ... | Locking issues aside, this presents a fair problem for the servlet container. How to know if any session attribute was modified per your example. I'm not saying this is necessarily a good idea, but you can byte compare the resulting session serialization to see if the session objects have changed. All you have to do is keep a local copy of the original session during the request. Not very pretty, but is a solution that wasn't discussed. I tend to agree with Costin that the session API isn't well suited for failover/distribution. I don't think it's impossible though. Plus, if you decide to develop an API separate from the session... it really starts to look like EJB. -Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
Mika Goeckel wrote: [ snip ] I'm not saying this is necessarily a good idea, but you can byte compare the resulting session serialization to see if the session objects have changed. All you have to do is keep a local copy of the original session during the request. Not very pretty, but is a solution that wasn't discussed. I tend to agree with Costin that the session API isn't well suited for failover/distribution. I don't think it's impossible though. Plus, if you decide to develop an API separate from the session... it really starts to look like EJB. I completely agree, that the API lacks proactive support for things in the background that may fail. But given the fact, that we support a reference implementation which has managed to provide really professional services to users (other ref implementations are just for demonstration, nobody would use them in production) and there are (commercial) solutions, that provide session fail-over in the limitations of this API, we **must** try to provide a solution. The API does not specify, how often the container may try to provide that service or what means it utilizes to do that. Nothing is 100% and I think it is better to live with the uncertaincy we discuss here than with the more likely problem that an instance fails and there is no potential replacement. For what it's worth, I completely agree. Failover is _never_ something that the app developer can completely ignore... no matter how much functionality the container provides. Developing distributed applications takes a little thought at the very least. And failover is just a simple distributed model. I've been reading all of this with great interest and waiting to see where it settles. I have alot of experience with various forms of distributed applications and it's interesting to see where they are similar. I'm really tempted to explore how a jini solution might be architected... just from the curiousity side more than anything. (I've been looking for a good excuse to dive deeper into jini.) Byte-comparison is not the worst solution. If we think about differential updates, byte comparison is a good candiate for that and surplus one that promises good performance. Interesting. I hadn't thought about differential updates using serialized streams. They tend to be kind of random but it might work. Also, I have written some classes before that can decode the binary streams as meta-data and now I'm thinking there might even be a clever diff that can be done by actually interpretting the data during the diff. I'll have to think about that some more. If the user wants to place things in a session that she does not need to be replicated, she has the option to declare them transient and write a getter that checks if the Attribute is present, otherwise reconstructs it (in the case of a picture, reloads it from disk). The user has the choice to design for performance or ease. We only need to document the options. Agreed. -Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
[EMAIL PROTECTED] wrote: On Tue, 13 Nov 2001, Mika Goeckel wrote: I completely agree, that the API lacks proactive support for things in the background that may fail. But given the fact, that we support a reference implementation which has managed to provide really professional services to users (other ref implementations are just for demonstration, nobody would use them in production) and there are (commercial) solutions, that provide session fail-over in the limitations of this API, we **must** try to provide a Well, the cool thing about open source is that we _don't_ need to implement all the bloat that commercial solution have. :) solution. The API does not specify, how often the container may try to provide that service or what means it utilizes to do that. Nothing is 100% and I think it is better to live with the uncertaincy we discuss here than with the more likely problem that an instance fails and there is no potential replacement. I think it's better to live with the certaincy that everything can ( and will ) fail and tomcat can't change this. The alternative is to give users the impression the data he puts in a session will be safe - and he may rely on that instead of using a transaction and a real API. Databases, EJB, etc are complex - but there's a reason to that. Well, we could argue about how much compexity is actually needed, but one thing is certain ( I hope ) - get/setAttribute is not enough, if you want data integrity you must use a different API ( in particular transactions ). Byte-comparison is not the worst solution. If we think about differential updates, byte comparison is a good candiate for that and surplus one that promises good performance. Byte compare every 5 seconds every object in session ? Let's say you just displayed the confirmation and charged the credit card, but the machine crashed just before you sent the order. ( or reverse - you sent it but didn't charged the credit card ). This should happen in below 5 seconds. I think the idea is that you'd byte compare on commit which ideally would happen at request boundaries. So in this case a single request becomes a transaction... which indeed opens up its own issues, but no bigger than the ones that were always there. The main issue is that the app has no control over this transaction. The case where things get strange is if the JVM dies in the middle of processing a single request. The request may have already committed real data to the DB, app server, whatever... and yet the session state up to the point of failure would be lost. Even five second polling wouldn't fix that case. In fact, that's the same case that fails in _every_ scenario that doesn't involve full EJB-like transaction support. As soon as you access one single piece of data that isn't covered by the transaction support, you lose some amount of failover recovery. Nothing short of full transaction support will ever cover the case of the dying JVM... and in some rare cases I think that will even fail. That being said, there may still be a place for a session-based distribution mechanism that can support load balancing, hot-swapping of tomcats, and basic failover. It should definitely be an opt-in sort of thing though, ie: web apps that meet the restrictions can opt to setup tomcat to provide this feature. If the user wants to place things in a session that she does not need to be replicated, she has the option to declare them transient and write a getter that checks if the Attribute is present, otherwise reconstructs it (in the case of a picture, reloads it from disk). The user has the choice to design for performance or ease. We only need to document the options. So the user should change all his objects to implement some arbitrary pattern just to fit this into our solution ? What if the object is not user defined ( like most are ) ? Well, we have to create wrappers for each objects you store in a session. Try to explain this on tomcat-user ( or tomcat-dev ) ... I agree... in these cases, the webapp could not be used with a distributed session environment. I think that's a given. Personally, I'm still trying to figure out if there are a large enough number of webapps that could be supported to make it worth the effort. (Heavy emphasis on effort.) -Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Craig,
It looks like this might be due to Bip committing a set of patches
that I sent him. So I might be able to help figure out why it's
broken. What exactly does it complain about?
Thanks.
-Paul Speed
[EMAIL PROTECTED] wrote:
craigmcc01/10/26 17:50:05
Modified:catalina build.xml
Log:
Add a kludge to avoid compiling the SSI servlet (and associated utilities)
because the build is currently broken, and I haven't seen the commit
message yet (due to the mail delay) in order to properly revert it.
Once the compile problems are fixed, simply uncomment the property
setting for compile.ssi, or include a setting like this in
build.properties:
compile.ssi=true
Revision ChangesPath
1.81 +8 -0 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- build.xml 2001/10/26 02:03:28 1.80
+++ build.xml 2001/10/27 00:50:05 1.81
@@ -233,6 +233,9 @@
equals arg1=${jdk.1.3.present} arg2=true /
/or
/condition
+!-- Uncomment this to compile the SSI code
+property name=compile.ssi value=true/
+--
condition property=compile.tyrex
or
equals arg1=${full.dist} arg2=on /
@@ -417,6 +420,7 @@
echo message=compile.jta=${compile.jta} /
echo message=compile.junit=${compile.junit} /
echo message=compile.ldap=${compile.ldap} /
+echo message=compile.ssi=${compile.ssi} /
echo message=compile.tyrex=${compile.tyrex} /
echo message=--- Distribution flags --- /
@@ -568,6 +572,10 @@
unless=compile.jmx/
exclude name=org/apache/catalina/net/SSLServerSocketFactory.java
unless=compile.jsse/
+ exclude name=org/apache/catalina/servlets/SsiInvokerServlet.java
+ unless=compile.ssi/
+ exclude name=org/apache/catalina/util/ssi/**
+ unless=compile.ssi/
exclude name=org/apache/catalina/valves/CertificatesValve.java
unless=compile.jsse/
exclude name=org/apache/naming/factory/MailSessionFactory.java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Ahah!
This is an easy one to fix. I just checked out the latest source and
it looks like Bip may have forgotten to cvs remove SsiMediator.java.
That's easy to do when you're updating a whole directory. Nuke this
file and everything should be good.
Let me know if you have any more problems.
-Paul Speed
[EMAIL PROTECTED] wrote:
craigmcc01/10/26 17:50:05
Modified:catalina build.xml
Log:
Add a kludge to avoid compiling the SSI servlet (and associated utilities)
because the build is currently broken, and I haven't seen the commit
message yet (due to the mail delay) in order to properly revert it.
Once the compile problems are fixed, simply uncomment the property
setting for compile.ssi, or include a setting like this in
build.properties:
compile.ssi=true
Revision ChangesPath
1.81 +8 -0 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- build.xml 2001/10/26 02:03:28 1.80
+++ build.xml 2001/10/27 00:50:05 1.81
@@ -233,6 +233,9 @@
equals arg1=${jdk.1.3.present} arg2=true /
/or
/condition
+!-- Uncomment this to compile the SSI code
+property name=compile.ssi value=true/
+--
condition property=compile.tyrex
or
equals arg1=${full.dist} arg2=on /
@@ -417,6 +420,7 @@
echo message=compile.jta=${compile.jta} /
echo message=compile.junit=${compile.junit} /
echo message=compile.ldap=${compile.ldap} /
+echo message=compile.ssi=${compile.ssi} /
echo message=compile.tyrex=${compile.tyrex} /
echo message=--- Distribution flags --- /
@@ -568,6 +572,10 @@
unless=compile.jmx/
exclude name=org/apache/catalina/net/SSLServerSocketFactory.java
unless=compile.jsse/
+ exclude name=org/apache/catalina/servlets/SsiInvokerServlet.java
+ unless=compile.ssi/
+ exclude name=org/apache/catalina/util/ssi/**
+ unless=compile.ssi/
exclude name=org/apache/catalina/valves/CertificatesValve.java
unless=compile.jsse/
exclude name=org/apache/naming/factory/MailSessionFactory.java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
And for what it's worth...
Here is a piece of the e-mail I sent to Bip... just in case anyone
is curious what I changed. (I sent the e-mail to him directly since
tomcat-dev was on 14 hour delay at that time and he said he was
going to be out of contact for a while.)
The patches fix one major issue and include several enhancements.
The main fix is that concurrent access to the SSI module was broken
before and would most readily manifest itself as broken nesting.
But the same problem would occur if two clients hit the server at
the same time. One would see the other's output.
As far as enhancements, I've added support for the set directive
and variable substitution. (i.e.: $someVar and ${someVar} are now
allowed in the appropriate places.) The initial support for
conditionals has also been added. I just need to make the
SsiCommands for if, else, etc..
So, with the above changes, SSI should be safe to use from multiple
clients. Locally, I've also finished coding the conditional
directives and some other fixes to SsiInvokerServlet. I'll post
those changes later today just in case someone wants to use or commit
them.
-Paul Speed
Paul Speed wrote:
Ahah!
This is an easy one to fix. I just checked out the latest source and
it looks like Bip may have forgotten to cvs remove SsiMediator.java.
That's easy to do when you're updating a whole directory. Nuke this
file and everything should be good.
Let me know if you have any more problems.
-Paul Speed
[EMAIL PROTECTED] wrote:
craigmcc01/10/26 17:50:05
Modified:catalina build.xml
Log:
Add a kludge to avoid compiling the SSI servlet (and associated utilities)
because the build is currently broken, and I haven't seen the commit
message yet (due to the mail delay) in order to properly revert it.
Once the compile problems are fixed, simply uncomment the property
setting for compile.ssi, or include a setting like this in
build.properties:
compile.ssi=true
Revision ChangesPath
1.81 +8 -0 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- build.xml 2001/10/26 02:03:28 1.80
+++ build.xml 2001/10/27 00:50:05 1.81
@@ -233,6 +233,9 @@
equals arg1=${jdk.1.3.present} arg2=true /
/or
/condition
+!-- Uncomment this to compile the SSI code
+property name=compile.ssi value=true/
+--
condition property=compile.tyrex
or
equals arg1=${full.dist} arg2=on /
@@ -417,6 +420,7 @@
echo message=compile.jta=${compile.jta} /
echo message=compile.junit=${compile.junit} /
echo message=compile.ldap=${compile.ldap} /
+echo message=compile.ssi=${compile.ssi} /
echo message=compile.tyrex=${compile.tyrex} /
echo message=--- Distribution flags --- /
@@ -568,6 +572,10 @@
unless=compile.jmx/
exclude name=org/apache/catalina/net/SSLServerSocketFactory.java
unless=compile.jsse/
+ exclude name=org/apache/catalina/servlets/SsiInvokerServlet.java
+ unless=compile.ssi/
+ exclude name=org/apache/catalina/util/ssi/**
+ unless=compile.ssi/
exclude name=org/apache/catalina/valves/CertificatesValve.java
unless=compile.jsse/
exclude name=org/apache/naming/factory/MailSessionFactory.java
--
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]
[PATCH] SSI support
Hello, I realize Bip is away, but I thought I'd post these anyway before I forget about them. Since I've had problems with multiple attachments I went ahead and stuck the files on my web site at: http://www.progeeks.com/pspeed/tomcat/SSIPatches.html Each file has a description of what it contains and where it should go. If a committer chooses to apply them and has problems then let me know. Here is the description of the changes from the above-linked page: What I did... The changes to SsiInvokerServlet should be independent of the other changes. Really, I just improved parsing support to handle escaped characters, etc. and be more error-compatible with Apache. The other SSI commands were modified to be more compatible with Apache SSI. Specifically, I've verified that the supported tags should work the same as mod_include in Apache 1.3.22. At least they support the same options. The tags were also enhanced to fit with the new conditional tags. I also added the implementation of the conditional tags: if, elif, else, and endif. This includes an expression parser. It's been a while since I've written a parser and I tried to do it with a slant on understandability. There's probably room for improvement, but it works the same as Apache on all of the tests I've tried... and it passed all of the new tester pages which generate identical output to Apache 1.3.22. So after these patches, the only tags that are missing that mod_include has are printenv and perl (which is conditionally included anyway). Also, the encoding parameter on echo is silently ignored right now. Thanks, -Paul Speed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
:)
At least the lag was shorter this time.
-Paul
Craig R. McClanahan wrote:
On Sat, 27 Oct 2001, Paul Speed wrote:
Date: Sat, 27 Oct 2001 11:34:58 -0400
From: Paul Speed [EMAIL PROTECTED]
Reply-To: Tomcat Developers Mailing List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
Craig,
It looks like this might be due to Bip committing a set of patches
that I sent him. So I might be able to help figure out why it's
broken. What exactly does it complain about?
Try compiling the current HEAD branch from source, with the
compile.ssi property set to true, and you'll see the four errors that
it creates. I'm not where I can do this for you right at the moment.
Thanks.
-Paul Speed
Craig
[EMAIL PROTECTED] wrote:
craigmcc01/10/26 17:50:05
Modified:catalina build.xml
Log:
Add a kludge to avoid compiling the SSI servlet (and associated utilities)
because the build is currently broken, and I haven't seen the commit
message yet (due to the mail delay) in order to properly revert it.
Once the compile problems are fixed, simply uncomment the property
setting for compile.ssi, or include a setting like this in
build.properties:
compile.ssi=true
Revision ChangesPath
1.81 +8 -0 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -r1.80 -r1.81
--- build.xml 2001/10/26 02:03:28 1.80
+++ build.xml 2001/10/27 00:50:05 1.81
@@ -233,6 +233,9 @@
equals arg1=${jdk.1.3.present} arg2=true /
/or
/condition
+!-- Uncomment this to compile the SSI code
+property name=compile.ssi value=true/
+--
condition property=compile.tyrex
or
equals arg1=${full.dist} arg2=on /
@@ -417,6 +420,7 @@
echo message=compile.jta=${compile.jta} /
echo message=compile.junit=${compile.junit} /
echo message=compile.ldap=${compile.ldap} /
+echo message=compile.ssi=${compile.ssi} /
echo message=compile.tyrex=${compile.tyrex} /
echo message=--- Distribution flags --- /
@@ -568,6 +572,10 @@
unless=compile.jmx/
exclude name=org/apache/catalina/net/SSLServerSocketFactory.java
unless=compile.jsse/
+ exclude name=org/apache/catalina/servlets/SsiInvokerServlet.java
+ unless=compile.ssi/
+ exclude name=org/apache/catalina/util/ssi/**
+ unless=compile.ssi/
exclude name=org/apache/catalina/valves/CertificatesValve.java
unless=compile.jsse/
exclude name=org/apache/naming/factory/MailSessionFactory.java
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
I couldn't find alot of info on testing. I also couldn't find any
tests that included multiple files... so I may be looking in the wrong
place. I eventually found and played with the tester stuff.
Attached are the files I added to the tester to exploit the include
problem. SSIInclude09.shtml simply includes another .shtml file
twice.
Here is the section I added to tester.xml to get the test to run.
tester host=${host} port=${port} protocol=${protocol}
request=${context.path}/SSIInclude09.shtml debug=${debug}
golden=${golden.path}/SSIInclude03.txt/
I now have this working on my system here. It currently passes all
of the tester tests in addition to about 7 more tests that I added
myself here locally. I also added the initial support for the set
directive and variable substitution. I have one more command to get
working and then some clean-up and I'll see about posting the diffs.
Actually, while I'm on that subject, the diffs are extensive since
I've pretty much touched every SSI related file in a very significant
way... in addition to removing a few of them. What is the preferred
way to submit such a large patch?
Thanks,
-Paul Speed
Bip Thelin wrote:
-Original Message-
From: Paul Speed [mailto:[EMAIL PROTECTED]]
For the curious reader, after looking into this code at some length
it seems clear why the set command was not added. All SSI requests
share the same environment, which not only makes a set command
impossible but also means that multiple SSI requests (or even nested
SSI requests) trample all over each other. A simple shtml file that
includes two other shtml files illustrates this quite nicely.
Do you have a smal testcase? We have unittests with Tomcat that have
nested includes and several includes in one page. All Ssi directives
share the same enviroment per page through a mediator, this is due to
the fact that you can have a config directive that changes the error
message that you would get for a failed include further down on the same
page, for instance.
However if pageA includes pageB, if pageB is also an shtml/ssi file it
would have a new fresh enviroment and could not tamper with pageA's
enviroment.
So you could easily do a set command simmilar to the config command.
Since I'm between assignments at the moment, I'm working on a patch
here locally. It's pretty significant, though, so it may take me a
few days. It will include the set command though since that's what
I'm going to use to test it. :)
Patches and additions are gladly appreciated.
Bip Thelin
This is Content of includeme.shtml
This is Content of includeme.shtml
Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
Bip Thelin wrote: -Original Message- From: Paul Speed [mailto:[EMAIL PROTECTED]] For the curious reader, after looking into this code at some length it seems clear why the set command was not added. All SSI requests share the same environment, which not only makes a set command impossible but also means that multiple SSI requests (or even nested SSI requests) trample all over each other. A simple shtml file that includes two other shtml files illustrates this quite nicely. Do you have a smal testcase? We have unittests with Tomcat that have nested includes and several includes in one page. All Ssi directives share the same enviroment per page through a mediator, this is due to the fact that you can have a config directive that changes the error message that you would get for a failed include further down on the same page, for instance. Actually, SsiInvokerServlet has a static reference to SsiMediator. Furthermore, all of SsiMediators fields are static. A simple test case that I use is a .shtml page that includes the same .shtml page twice. Only the first one will actually be included because of the way the Request object in SsiMediator is overwritten. However if pageA includes pageB, if pageB is also an shtml/ssi file it would have a new fresh enviroment and could not tamper with pageA's enviroment. So you could easily do a set command simmilar to the config command. Actually, includes should share the environment of the parent... in fact, if they set server variables the parent will see them. Since I'm between assignments at the moment, I'm working on a patch here locally. It's pretty significant, though, so it may take me a few days. It will include the set command though since that's what I'm going to use to test it. :) Patches and additions are gladly appreciated. Cool. I'm almost done refactoring. I'm basically replacing the SsiMediator with an SsiEnvironment that is then stuck into a request attribute. In the process, I'm moving some things around a little since all of the commands were relying on the fact that they were SsiMediator subclasses... and therefore directly accessing the static fields of SsiMediator. Hopefully I'll have something done in the morning. Even more hopeful, it will be worth committing. ;) We'll see... -Paul Speed
Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
On a vaguely related note... For the curious reader, after looking into this code at some length it seems clear why the set command was not added. All SSI requests share the same environment, which not only makes a set command impossible but also means that multiple SSI requests (or even nested SSI requests) trample all over each other. A simple shtml file that includes two other shtml files illustrates this quite nicely. Since I'm between assignments at the moment, I'm working on a patch here locally. It's pretty significant, though, so it may take me a few days. It will include the set command though since that's what I'm going to use to test it. :) If noone else beats me to it, I'll post it when I'm done. -Paul Speed [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4361. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4361 SsiServlet potentially leaks files --- Additional Comments From [EMAIL PROTECTED] 2001-10-23 12:39 --- I can't recreate the error here but I did happen to notice something as I was browsing through the code. Each SsiInvokerServlet request causes it to open the requested file as a Resource. The InputStream that is obtained from this Resource is never closed. I tried to poke around in the Resource classes to see if some magic was closing the stream but couldn't find anything. I can attach a patch if needed, but the change is pretty simple. Just a try/finally with a close().
Re: DO NOT REPLY [Bug 4339] - Cannot use // comments in JSP code
Only partially related to the bug, so I'm replying directly instead of through bugzilla... Does this mean that JSP uses a different Java language specification? If so, where can I find this separate specification? Are there any other big things like this that are incompatible with normal Java syntax? Thanks, -Paul Speed [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4339. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4339 Cannot use // comments in JSP code [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-22 10:11 --- You should not be using // comments. You have absolutely no control over the Java code that is generated for your page, so it is your responsibility to use well-formed constructs. In this particular case, that means to use /* */ style comment markers so that you can explicitly close them. Even if we changed Tomcat to do what you suggest, depending on this would not be portable and you'd have massive problems as soon as you tried to switch to some other container that didn't do it. Using scriptlets at all can lead you into lots of other problems (such as intermixing business logic and presentation logic that makes it very hard to maintain and enhance your applications), but that is a whole separate discussion.
Re: DO NOT REPLY [Bug 4339] - Cannot use // comments in JSP code
Ah, Sorry. _That_ makes perfect sense. It's what I get for not reading the original bug report in more detail. Although, I would expect in the following case... When you do something like this: % System.out.println(); // Hello % Some template text then this gets translated into System.out.println(); // Hello Some template text To instead get: System.out.println(); // Hello out.print( Some template text ); Since Some template text is clearly outside of the % %, wouldln't it be turned into generated output instead of code? Or am I being pedantic and what you really meant was: System.out.println(); // Hello out.print( Some template text ); or somesuch? -Paul Speed Craig R. McClanahan wrote: On Mon, 22 Oct 2001, Paul Speed wrote: Date: Mon, 22 Oct 2001 13:48:08 -0400 From: Paul Speed [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 4339] - Cannot use // comments in JSP code Only partially related to the bug, so I'm replying directly instead of through bugzilla... Does this mean that JSP uses a different Java language specification? If so, where can I find this separate specification? Are there any other big things like this that are incompatible with normal Java syntax? The JSP specification does not mandate the use of Java as a scripting language -- you can use any language you want (as specified by the language attribute of the %@ page % directive). However, many of the features related to scripting are defined *only* for Java. Note also that Jasper (the JSP page compiler in Tomcat) only supports Java as a scripting language at the moment. However, more germane to this bug report: * Scriptlets are required to be well-formed according to the rules of the scripting language in use (JSP 1.2, Section 2.11.2). Thus, if you mistakenly leave off a semicolon at the end of a Java statement in a scriptlet, the compilation error you get is your fault. It's also your fault if the scope of your language element extends outside the closing % delimiter in a manner that causes invalid code to be created (such as mismatching } brackets), or the case described in the following point. * Scriptlets are translated into the generated code according to the following rule (JSP 1.2, Section 6.4.2): % scriptlet % --scriptlet In other words, no newline is added after the % by the page compiler (though the developer could certainly put a newline there). When you do something like this: % System.out.println(); // Hello % Some template text then this gets translated into System.out.println(); // Hello Some template text and you get what you pay for. If you want to use // comments, do this instead: % System.out.println(); // Hello % Some template text and it will work fine. Thanks, -Paul Speed Craig [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4339. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4339 Cannot use // comments in JSP code [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-22 10:11 --- You should not be using // comments. You have absolutely no control over the Java code that is generated for your page, so it is your responsibility to use well-formed constructs. In this particular case, that means to use /* */ style comment markers so that you can explicitly close them. Even if we changed Tomcat to do what you suggest, depending on this would not be portable and you'd have massive problems as soon as you tried to switch to some other container that didn't do it. Using scriptlets at all can lead you into lots of other problems (such as intermixing business logic and presentation logic that makes it very hard to maintain and enhance your applications), but that is a whole separate discussion.
Re: Extending Server.xml configurability (foradditionalclasspaths)
Just clarifying, you basically want the exact same functionality you'd get by copying the jars into the individual webapp lib directories, but you just don't want to have to copy them. Right? -Paul Speed Rick Mann wrote: on 8/30/01 4:22 AM, Glenn Nielsen at [EMAIL PROTECTED] wrote: Why won't installing the jar files in $CATALINA_HOME/lib and making them available to all web applications meet your requirements? Is there a security reason why some web applications can use the classes and others should not? Yes. In particular, I may have a set of classes I want to make available to my contexts an no one else's. Or perhaps I own a limited-use license on some common classes. Imagine an ISP running Tomcat in a virtual-host configuration. Do the java classes being shared have static methods and data that needs to be shared across this subset of web applications, but not other web apps? No, I don't think data need be shared across any contexts, nor do I think you'd want to. It really opens up a can of worms to allow contexts to share data in memory like that (IMO). I'm assuming individual contexts have private data. I am trying to determine what you want to accomplish and why, not how you want to do it. Once we know what you want to accomplish it will be easier to determine how to do it within Tomcat 4. Sure, that makes perfect sense. I don't require being able to extend a context's class search path, that just seems to be the most appropriate place to do so. Comments: If you need to restrict access to an API for security reasons there are ways to do that using the Java SecurityManager configuration and permissions granted in the security policy file. If you tell me how this is done, I'll let you know if that solves my problem. Chances are it does not, because I can't give access to a directory to the owner of some contexts, and say put your common classes in here. I have to give access to the CATALINA_HOME/lib|classes dir to every owner of a context and I don't want to have to do that. But I'm always open to suggestion. Thanks! Roderick Mann rmann @ latencyzero.com.sansspam
Re: Extending Server.xml configurability (foradditionalclasspaths)
I wasn't trying to be rude. I was just summing up a fairly large discussion that touched on everything from classloader sharing to security to where any changes would reside. You want several web apps to have access to the same jar file as if each had their own private version, ie: no sharing of static data or security permissions or any of that. -Paul Speed Rick Mann wrote: on 8/30/01 11:36 PM, Paul Speed at [EMAIL PROTECTED] wrote: Just clarifying, you basically want the exact same functionality you'd get by copying the jars into the individual webapp lib directories, but you just don't want to have to copy them. Right? Look, if it were the exact same functionality as copying the classes/jars into the individual webapp's folders, then that's what I'd do. However, it's not the same thing. It makes deployment and development more difficult, despite the possibility of creating scripts or ant files to automate this process, it's still not as easy as being able to put the classes in one place once. If it makes you happy, yes. I want the exact same functionality as copying a set of class files/jar files into a subset of installed webapp's directories without copying them or making links from one dir to another. Roderick Mann rmann @ latencyzero.com.sansspam
Re: Sources in Binary Distributions
Why not have three different downloads? src, bin, and src + bin. (ie: can't we all just get along? ;) ) -Paul Speed Rob S. wrote: So what we have here is a minority of developers who look through the Tomcat source, versus the majority of people who have no interest in the /src dir. The argument is leave src in there so that when I want to look at the source, i don't have to download a src dist. For some reason, the keep it in there argument almost makes it sounds like the src is unavailable unless it's in the bin build. Personally, for all of the people that could care less about the source, I don't think it's asking much for people who want to look at the source to go and get it...? - r -Original Message- From: Loïc Lefèvre [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 12:10 PM To: [EMAIL PROTECTED] Subject: RE: Sources in Binary Distributions Absolutely agree with you! -Message d'origine- De : Arun Katkere [mailto:[EMAIL PROTECTED]] Envoyé : jeudi 2 août 2001 17:28 À : '[EMAIL PROTECTED]' Objet : RE: Sources in Binary Distributions I don't generally throw in my $0.02 into a well worn thread and add to the noise , but there is another issue which I didn't see anyone bring up. Having source around helps you with debugging. And if that results in better bug reports, i.e., instead of it doesn't work and here is the stack trace, you get it doesn't work because you didn't check for null around this line of this file, it is probably worth it. Keep in mind that many of Tomcat users are competent Java developers. And we are not talking about the entire build system here. Just the basic .java files. Not even native components (which don't aid in this purpose). Sun's Java2 SDK includes the source (just the .java files) for I suspect the same reason. Personally, I download the source distribution only when there is a critical issue in Tomcat that we need resolved now, and patch and build with that fix. Source in the binary on the other hand is useful for many reasons even if you discount the first step towards getting people involved argument. A quick check of some aspect of servlet/JSP spec(without going through 100s of pages of PDF). Help quickly identify whether the issue is with Tomcat or your code. All on machines where you typically don't have the full development environment set up (when we are talking about JSP and not servlets). Of course, one can always download the source distribution. So, if you are set on saving folks a few seconds (or minutes) of download time at a slight cost for those of us who do find it invaluable, that's fine. -arun -Original Message- From: Rob S. [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 02, 2001 4:19 AM To: [EMAIL PROTECTED] Subject: RE: Sources in Binary Distributions I'd like to second that. I am currently not involved in any active development, but looking at sources contained in a binary dist is certainly the first step towards getting involved (its on my list (o: ) So you *expect* the /src dir in a binary dist? That's mind-blowing to me. If you're interested in TC development, your first thought isn't Time to go d/l the src distro it's Time to d/l the bin dist so I can check out the src ? I'm not making a huge stand here, I thought bringing up the suggestion was almost common sense. It's a bin dist, i.e. !(src included). I wouldn't expect it to be there shrug - r
Re: [VOTE] Sources in Binary Distributions
Pier P. Fumagalli wrote: Pier P. Fumagalli at [EMAIL PROTECTED] wrote: [ ] - +1 Remove the sources [I will help in the process, meaning do the job] [ ] - +0 Remove the sources [I can't help, won't help] [X] - -0 Leave the sources [But since I don't volunteer this is not binding] [ ] - -1 Are you nuts? Sources are there and there have to remain. Comments: (required for -1) It's a totally pointless discussion... Everyone always included sources in binary distros... Everyone who? jakarta/apache? I would agree with that. Other projects seem to name binary and source distributions appropriately. I would at the very least argue that the name binary distro is wrong. So, I'm for the peace and quiet and leave things as are now. But, since I'm a nice guy, I don't make it pending... (Pointless to overiterate on the advantages to see the sources with the binaries, like the same .class and .java files all toghether.. Yadayadayada). But I'm just wasting bandwidth (like the rest of this thread!) On a sidenote... If we have an installer (like under Windows) I vote -1 for removing sources from that, and make it an optional component. So, my -0 is only for tarballs/zipballs (balls!) bah! (Go Remy!) Pier I personally don't understand what the big deal is. Some people want a binary only distribution, some want a binary+source distribution. Why not provide both? (Easy for me to say as a lurker.) For what it's worth, I would only download the bin+src distro, ie: the same one that's misnamed now. -Paul Speed
Re: [jtc] tabs policy??
[EMAIL PROTECTED] wrote: On Sun, 24 Jun 2001, Justin Erenkrantz wrote: That just leads to formatting problems because people don't understand that. If you must have tabs, they should be the same as the indention level, not some factor of the indention level. This doesn't have to be complicated. One tab == one indention level. I'm not sure I understand how you reached that conclusion, but this is what causes all the curent problems ( and the reason for people to consider tabs as evil ). Tab size is 8 - or at least used to be before the idea that you can configure this. What's evil is the fact that some editors allow you to change the size of the tab. In a text you can have multiple indentation levels, and it's true that on some typewriters you can use the TAB key to move to the next indentation level ( the same as you use ^A to move to beginning of line in some editors ). That doesn't mean the tab ascii code will have multiple sizes ( and change based on the position in the text). It just mean that stupid programmers decided it's easier to add a panel that changes the number of spaces equivalent with TAB instead of implementing code that uses spaces for indentations 8, and replaces 8 spaces with a tab symbol. And because someone decides to extend a ( de-facto ) standard, later on we have to abandon the standard and say it's evil. That happens very often, and we're so used with it that now it's almost a habit. Costin The way it always boils down on all of the projects I've worked on is that spaces always look right no matter what. Tab characters have the potential to cause problems. On the projects where we did not dictate that all developers should use a specific editor, we did dictate no tabs in source. Only spaces were allowed. This made sure that we didn't spend days criticizing each others' choices in editors and could instead write code. That could be the reason so many people gravitate towards arguing for no tab characters. It's not like the file space they save is as critical as it used to be 15 years ago. :) I personally don't care. I've learned to read it with tabs right or wrong. It looks just as cryptic to me as KR style bracing and I can read that just fine. ;) -Paul Speed
Re: FYI: Comment on DOXYGEN...
In another thread on this subject it was mentioned that someone was looking for a replacement to these tools. I, too, poked around a little but it occurred to me that I don't even know what the specific requirements for such a tool are. Might be worth discussion. Clearly both of the current tools have their problems. -Paul Speed Pier P. Fumagalli wrote: Even though DOXYGEN is used by APR right now to build their API docs, today, when I asked Ben about it he replied that It's written in bloody C++ and you need always the later version of the compiler to make it run... And given the current situation, I totally withdraw my idea of using it _at_all_ Pier (feeling bloody stupid :)
Re: FYI: Comment on DOXYGEN...
Pier P. Fumagalli wrote: Paul Speed at [EMAIL PROTECTED] wrote: In another thread on this subject it was mentioned that someone was looking for a replacement to these tools. I, too, poked around a little but it occurred to me that I don't even know what the specific requirements for such a tool are. Might be worth discussion. Clearly both of the current tools have their problems. Requirements? - Parse C (and optionally C++) - Derive documentation from JavaDoc style comments in sources Right, that's the part where it gets wierd. Assumptions can be made, like I assume you break down the docs based on file (in the case of C) since there are no classes. Ages ago I used a tool that required section tags in the comments. Ugly tool. For C++, it's a little more straight forward from an organizational standpoint. - Portable on any platform (no weird C++ code, Perl, Java, or ANSI-C) - Maybe have a decent abstraction for the generated documentation (kinda like the Doclet thinghie in JavaDoc, maybe even reusing that) Seems easy enough, but NOBODY ever thought about putting all those toghether... I agree. If I wasn't in poor, start-up company, working my butt off mode, I'd throw one together myself. Pier BTW, I checked out ANTLR (as someone suggested, a parser generator) and their GNU-C grammar, and the modification would be really huge, up to the point that it might be worth rewriting a new grammar, only for the JavaDOC style comments in source codes Yeah, in general, I prefer JavaCC. No tangible reasons, just warm and fuzzy ones. -Paul Speed
Re: synchronize keyword may produce deadlocks.
You do know your code has a typo that will cause deadlocks, don't
you? See below...
[EMAIL PROTECTED] wrote:
Hi,
The synchronize call may deadlock due to thread starvation. This is present
in all versions of java on all platforms i could test (jdk 1.1 thru 1.4b
on win/sol/lin)
Example code for interlock.java is as follows :
import java.io.*;
import java.lang.*;
public class interlock{
public static int test=0; // 0 - test java synchronize. 1 - test java regular
private static boolean atomic_spinlock1=false;
private static boolean atomic_spinlock2=false; public interlock(){}
public static void main(String[] args) throws InterruptedException {
log(InterlockTest : If this code completes test was a success.);
if(args.length==1){test=Integer.valueOf(args[0]).intValue();}
new interlock().startup();}
public static void log(String s){ System.err.println(+s); }
public static void blink(int
i){try{Thread.currentThread().sleep(10+i);}catch(Exception
e){}}
public static void spinlock1_rel(){atomic_spinlock1=false;}
public static boolean spinlock1_set(){
if (atomic_spinlock1==false) { atomic_spinlock1=true; return true; } else
{ return false; } }
public static void spinlock2_rel(){atomic_spinlock2=false;}
public static boolean spinlock2_set(){
if (atomic_spinlock2==false) { atomic_spinlock2=true; return true; } else
{ return false; } }
public static synchronized void s_spinlock1_rel(){atomic_spinlock1=false;}
public static synchronized boolean s_spinlock1_set(){
if (atomic_spinlock1==false) { atomic_spinlock1=true; return true; } else
{ return false; } }
public static synchronized void s_spinlock2_rel(){atomic_spinlock2=false;}
public static synchronized boolean s_spinlock2_set(){
if (atomic_spinlock2==false) { atomic_spinlock2=true; return true; } else
{ return false; } }
private void startup() { if (test==0) {log(Testing atomic spinlocks with
Java Virtual Machine sync ); }
else {log( Testing atomic spinlocks without Java Virtual Machine sync...);}
Runner y=new Runner(0);Runner s=new Runner(1); y.start();blink(100);s.start();
}
class Runner extends Thread implements Runnable{ private int runr=0;
Runner(int seq) { runr=seq; } public void run() { log( Started runner +runr+
-- );
log(runr+: Setting atomic spinlock 1...);
if (test!=0){while(spinlock1_set()==false){}} else {
while(s_spinlock2_set()==false){}
Note in the line above that test!=0 is setting spinlock 1 and the else
branch is setting spinlock 2. So, whenever you test the synchronized
version you are going to get a deadlock since your locking has no
thread identity... a thread can block itself by checking the lock
after setting it.
-Paul Speed
}
log(runr+: Set spinlock 1. Now sleeping... );
blink(1000); log(runr+: Finished sleeping. Now setting spinlock 2... (if
bug exists it will hang here...) );
if (test!=0){while(spinlock2_set()==false){}} else { while(spinlock2_set()==false){}
}
log(runr+: Spinlock 2 set. Now unsetting both spinlocks... );
if (test!=0){spinlock2_rel(); spinlock1_rel();}else{s_spinlock2_rel();
s_spinlock1_rel();}
log(runr+: Completed. ); }} }
BTW, my email has changed.
[EMAIL PROTECTED] -- [EMAIL PROTECTED]
Thanks.
-Ys-
Free, encrypted, secure Web-based email at www.hushmail.com
Re: JSP re-compile performance under heavy load
Just a thought, But might you not also just save your query results in some intermediate format (serialization might work) that your JSP pages could then use? It may not fit in well with your system, but it would save from having to recompile pages. At the other end of the spectrum, you could generate the HTML instead of JSP and also save the intermediate step. A large amount of JSP compilation overhead is out of tomcat's hands since it's reliant on the java compiler. -Paul [EMAIL PROTECTED] wrote: Hi All, I'm curious if any of you have code that tests the performance of JSP recompiles while tomcat is under load. I've read that some changes were made in this area recently, and it directly effects a design I'm considering. If performance testing code exists, could someone send it to me? Thanks, Jason Henriksen P.S.: (If you're curious how I got into this sitation, here's the rationale: ) Basically, I'm treating the disk drive as a cache. I expect to have well over 5,000 different query result pages, each of which could take over a minute to generate because they require some fairly thick SQL. The good news is that only about 100 of them will be 'active' at any given time. The non-active pages, can be built, saved on disk and then safely ignored (Thus being served with no database hit). However, when the object in the DB changes I should be able to show the update on the JSP page within 15 minutines of the database change occuring. My plan is to generate a page for each of my 5,000 objects up front and then wait until a DB object changes. When it does, I'll regenerate the page for just that object. That way everyone see's the new static page, and the database can continue doing it's regular job of managing user accounts, and other such non-cacheable business. (The disk cache is also preferable to holding the results for all 5000 object queries in memory because the results will be fairly large. My disk space is near infinite, but my memory is not). So if I have 1000 people looking at the results for Object A when it needs to be re-compiled how will Tomcat respond? I know it does fine job handling updated JSPs in a development environment, I'm curious how it's expected to perform doing that kind of operation under load. (I understand that my mileage my vary, I'm just looking for what you guys would expect to happen, or do you suggest some other desgin?) Thus, I'm look for test-code and/or result numbers. -- Warning : The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and then delete it from your computer. All e-mail sent to this address will be received by the Providian Financial corporate e-mail system and is subject to archiving and review by someone other than the recipient. ==
Re: 'Just say no to JSP'
Paulo Gaspar wrote: Earl, If you think one should not discuss the merits of JSP here, you should not take part on it even if to defend JSP. If you agree we should talk about the pros and cons of JSPs, it is hard to talk about the cons of JSP in a constructive way without pointing alternatives. Can one just say it is bad without pointing alternatives and still give worthy input? Or do you just want to talk about the pros? =;o) Clearly, there are some problems with JSPs. Supporting a clear separation between logic (scripting) and presentation (templating) is not easy to enforce with JSPs. And this is a discussion going on in many forums. Now, JSPs are nice for scripting stuff (when you want to code and see the result with no compiling/restarts). I even thought of using JSPs for the scripting with Velocity for templating!!! And this is not such new idea since there are people using JSPs with XSLT for the same purposes. But XSLT just makes things too hard. Too much cost for not enough profit. I just converted a XSLT based application to Velocity and I sure know what I am talking about. Maybe JSPs just need something extra for the templating side. Maybe JSPs can learn that from Velocity/WebMacro template engines. And this list is one of the best spots to talk about this. The right people read this. * Isn't Tomcat the reference JSP implementation? * Is is. But the tomcat team doesn't set the spec, it just implements it. -Paul Have fun, Paulo Gaspar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 06, 2001 18:48 Why has the tomcat-dev list become a Velocity advocacy list?? Isn't the purpose of this list supposed to be for communation between Tomcat developers? Is velocity recruiting or something? =eas=
Re: [report] Classloading problems between Catalina and Cocoon
Tom Reilly wrote: +1 There's no reason going from .java to a Class object should be any harder than going from .class to a Class object. If the compiler used ClassLoader's instead of manually reading .class files in through the file system, fast in-memory compilation becomes a possibility (and your runtime classpath becomes the same as your compiler classpath). Possibly. The thing is that loading classes through a ClassLoader has an extreme amount of overhead. When the compiler accesses the class, all of its static initializers would be run. None of this stuff is necessary for basic compilation. Reading the .class files as resources (I'm pretty sure) has the same problem. At least, we were never able to resolve the problem when attempting to do something similar, but things have changed a lot since then. Loading .class files as resources might work now. -Paul That said, I think javac is never going to be this compiler, at least not any time soon. They just re-wrote it and I doubt they'll do it again. A more mobile open source project like KJC is probably more realistic. "Pier P. Fumagalli" [EMAIL PROTECTED] writes: James Duncan Davidson [EMAIL PROTECTED] wrote: on 2/15/01 10:12 AM, Stefano Mazzocchi at [EMAIL PROTECTED] wrote: today's java compilation technology stinks! Or rather, the method of accessing today's Java compiler stinks. Nono, the whole technology stinks. To include Java classes JAVAC doesn't rely on the classloader, but on single File objects, and that causes problems when compiling stuff like JSP... Pier and I started talking about a JSR for Java Compilation API months ago and I even wrote a JSR-ignition document but the 'javac' team sucked it, well, I don't know anything about it. I'll check up on this. We were talking with Bill Maddox, and apparently, he left Sun for Transmeta without saying anything. That's why the whole discussion went down the drain. Just a FYI.. Pier -- Tom Reilly Allaire Corp. http://www.allaire.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Thread-safety
"Klemme, Robert, myview" wrote:
hi all!
-Original Message-
From: Luc Vanlerberghe [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 6:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Thread-safety
Does this mean that the following code would be thread safe?
NO, it's not!
sorry to intervene here. i think you are wrong. look at it again:
[...]
Does this mean that the following code would be thread safe?
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
synchronized(new Object()) {_jspx_init();}
_jspx_inited = true;
}
}
}
this double check is a usual technique to improve performance. the inner
check is necessary for proper operation. the outer check improves
performance since it does not require a lock on the object to be acquired
which is relatively costly.
The problem is that the point of the code block is to be
sure that the _jspx_init() method has been completed before
proceeding. The problem is that _jspx_inited might appear to other
threads to be set to true before the original thread has completed
executing the _jspx_init() method (or at least before its changes
are available to other threads).
This means that the second thread would come through, see
that _jspx_inited is true, and skip the synchronization block. That
threads execution would then proceed thinking that everything has
been initialized when it hasn't.
and, btw. why did they not code this:
if ( ! _jspx_inited ) {
synchronized (this) {
if ( ! _jspx_inited ) {
// other initialization stuff
_jspx_inited = true;
}
}
}
i think it is quite superfluous to compare a boolean with true or false
(apart from the fact that in other programming languages this might even be
dangerous, just think of C...)
Check out the article that is referenced in other mail in
this thread or hit JavaWorld and see the references section on the
article about singletons.
-Paul Speed
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Thread-safety
Steve Downey wrote:
That code has also been found to be _not_ thread safe. Much to the surprise
and dismay of several experts.
See: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
The "Double-Checked Locking is Broken" Declaration
-Original Message-
From: Ethan Wallwork [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 11:51 AM
To: [EMAIL PROTECTED]
Subject: RE: Thread-safety
"When the thread exits the synchonized block, it is required to commit all
its
changes to main memory"
Does this mean that the following code would be thread safe?
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
synchronized(new Object()) {_jspx_init();}
_jspx_inited = true;
}
}
}
BTW, is the _jspx_init() method private and/or final?
Otherwise, can compilers really get away with inlining virtual
methods? Or is this just a Hotspot runtime compilation issue?
-Paul Speed
The inner synchronized block should ensure that the initialization gets
commited before _jpsx_inited gets set to true.
Fun stuff!
--
Ethan
-Original Message-
From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 5:03 AM
To: [EMAIL PROTECTED]
Cc: Justyna Horwat
Subject: Re: Thread-safety
Luc Vanlerberghe [EMAIL PROTECTED] wrote:
Thanks for incorporating this change to jasper. I had suggested it a
couple of months ago (22/11/2000 in fact: see
http://w6.metronet.com/~wjm/tomcat/2000/Nov/msg00747.html)
In the meantime, however, I have been browsing through the sessions of
the JavaOne conference of 2000 and there's (at least) one session of
particular interest: "Correct and Efficient Synchronization of Threads
in the Java Programming Environment" (The complete list including links
to realAudio recordings is on
http://java.sun.com/javaone/javaone00/replay.html)
Here's a direct link to the abstract:
http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=754
One of the points that is made in that session is that even this
'double-check idiom' is NOT thread-safe!
The exact reasons for this are not so easy to understand but basically
what I understood is that within the synchronized block, writes to main
memory can occur in any order, meaning that the value of _jspx_inited
can be commited to main memory while some of the results of the
initialisation code are still in e.g. processor registers. When the
thread exits the synchonized block, it is required to commit all its
changes to main memory, but if another processor checks the value of
_jspx_inited *before* acquiring the lock, it may see _jspx_inited being
true while not all other initialisation data has actually been written
to main memory.
For more details, please follow the links above...
GOTCHA! I was looking at your post with Justy this afternoon and didn't
understand why it's not "threadsafe"... What she committed (without the ugly
writer.println() stuff is:
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
}
So, if the commit of the _jspx_inited value can occour while _jspx_init() is
still in progress (let's imagine some weird code optimization techniques),
to fix this bug, we should simply remove the first line of the commit and
simply write:
synchronized (this) {
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
So that, no matter what happens, a thread must ALWAYS acquire a lock on the
synchronized piece of code, and so we are guaranteed that _jspx_init() is
called at least once all the time...
Yep, makes sense...
Pier
--
Pier Fumagalli mailto:[EMAIL PROTECTED]
I'm selling my Sony Vaio Z505. Check out http://www.betaversion.org/~pier/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error, please notify
the sender via e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Thread-safety
Marc Saegesser wrote:
This is a truly fascinating thread of discussion. However, from reading the
article _The "Double-Checked Locking is Broken" Declaration_
(http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
It seems to me that the following code is thread safe.
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_init();
_jspx_inited = true;
}
}
}
The case described in the article is the following
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other functions and members...
}
}
The problem is that helper may be assigned a value before the Helper
constructor executes. Thus another thread may come along and notice a
non-null value for helper and attempt to use un-initialized values.
In the _jspx_inited case above the only requirement is that compiler can't
rewrite the code into the equivalent of
if (_jspx_inited == false) {
synchronized (this) {
if (_jspx_inited == false) {
_jspx_inited = true;
_jspx_init();
}
}
}
Such a re-ordering seems illegal to me (what if jspx_init() uses the value
of _jspx_inited?). If, however, it is legal reordering then the example of
a "correct" double-check mechanism for 32-bit primitive values should work
here. It would look something like
boolean tmpInited = _jspx_inited;
if (tmpInited == false) {
synchronized (this) {
if (tmpInited == false) {
tmpInited = _jspx_init(); // NOTE: _jspx_init() needs to
return true
_jspx_inited = tmpInited;
}
}
}
The issue as I understand it is that the constructor might
have been inlined and then the inlined instructions may have been
re-ordered. If _jspx_init() can be inlined then it might exhibit
the same problem. My question is what the spec says about inlining
virtual methods... I'm pretty sure that _jspx_init() is only a
candidate for inlining through runtime compilation by Hotspot. But
I'm not even sure of that.
Otherwise, if it can never be inlined then your original
assertion is correct.
-Paul Speed
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
Mel Martinez wrote:
Without getting into the larger issue, one problem
that jumped out at me from your article is (at least
in your examples) the MLS precompile looks at the
expression inside the digraphs and replaces line
terminations in the *.j source with linefeed
characters ('\n'). That presumes the line termination
character of choice for the output is a linefeed
character. It may be a '\n' is fine for most cases,
but the truth is that it depends on the platform upon
which the output is to be used. In generall, it is
always best to use the line.separator property instead
or use a PrintWriter's println() method to insert the
correct line termination.
Another issue is that the example creates catenated
String literals. I would hope that the actual code
produced would use appropriately initialized
StringBuffers or performance could be a problem.
Just thought that I would point out that:
"My " + "dog " + "has " + "fleas." will be compiled as one String:
"My dog has fleas." and incurs no runtime penalties. In the case
of literals it can be more efficient than StringBuffer as long as
they are grouped together as above. Since I haven't looked at the
code directly, I don't know how or if this affects your point.
-Paul Speed
Just some thoughts on the implementation. On the
larger issue of this thread, I don't really see the
benefit of something like MLS over JSP, which
potentially allows you to completely remove all Java
code from the html (by using jsp tags and taglibs),
but take that as an imho.
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- Brad Cox [EMAIL PROTECTED] wrote:
At 11:30 AM -0500 01/11/2001, Shawn McMurdo wrote:
I agree with most of your discussion of the
disadvantages of JSP/ASP/etc,
but I believe your solution does not address a
fundamental problem, which
is the complete separation of presentation
resources from presentation logic.
That is correct. My goal at this point is to get
free of JSP so the
goal was only to duplicate what JSP does in a way I
can live with.
Having the HTML embedded in a java class may be
suitable for small
applications
built by engineers but does not address the vast
majority of applications
where designers work on HTML using many different
HTML editing tools
while developers work on the application logic in
Java using various IDEs and
editors.
Perhaps I miscommunicated. The private methods that
contain the
{{html}} need not be private methods in the
controller class,
although that is the style I demonstrated in the
paper and that I use
in my own I-do-it-all work.
Also there is nothing that requires these view
methods to contain
hardcoded strings, other than the crude measurements
in the
Conclusion section that makes me doubt that the
space issue is a
primary concern. Each method could aim MLS at an
html file at runtime
(using the doStream() method that it provides for
this purpose but
which I didn't mention in the article) and let it do
the executable
inclusion at runtime. But good point; I'll make this
explicit in the
article.
This would also eliminate the need for the outermost
enclosing {{...}}, but
the executable inclusion brackets would remain. Do
you object to my
belief that html experts and their tools couldn't be
trained to
ignore the {{...}} wrappers around the html? I'd be
interested in
hearing more about this. After all, JSP has the same
problem its %=
... % executable inclusion syntax.
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
"Craig R. McClanahan" wrote: Paul Speed wrote: [EMAIL PROTECTED] wrote: Can you argue about how Valve's single chain of command ( where authentication, generation, etc are done in a single invoke() ) can be better than what all other server are doing ( and Apache 2.0 moves to a different level with the flexible HOOK mechanism ? Actually, this is a discussion I would like to see happen. I think that I can actually argue for Valves. Admittedly, I know little about the actual implementations but I am very familiar with the patterns used in Tomcat 3.x and Tomcat 4.x and I have seen much of the discussions on this list. However, in other projects I have converted several architectures using patterns similar to 3.x to be more like the Valve approach. We did it to shorten development times and improve developer productivity. Performance wasn't our main goal but in all but one case performance improved. Valves implement the "Chain of Responsibility" design pattern in the GoF book. You will also see a very similar programming model in the way that the javax.servlet.Filter APIs are defined in the Servlet Specification, Version 2.3 Proposed Final Draft -- after wrestling with lots of alternatives, the expert group concluded that this was the most appropriate programming model for exposing similar functionality at the application level. Yeah, I've used variations on this pattern to help save architectures that were spiralling out of control. What I would like to see is a frank analysis of this topic. If those "in the know" do not have the time then I will attempt to do a brief analysis myself in the coming weeks. It will take research on my part whereas some of you might know the answers off the top of your head. I did an analysis on this topic in August, when Catalina was being formally proposed -- it is still in the "jakarta-tomcat-4.1" CVS repository as file "catalina/docs/filters.html". The comparison was primarily to the way that request interceptors were implemented in Tomcat 3.2, so I would suspect that there have been some changes since on the HEAD branch -- particularly in the last section, where I discuss limitations that are due to the *implementation* of request interceptors in Tomcat 3.2, not their *design*. (The Valve APIs have not needed to be changed -- they have proven to be entirely sufficient to implement the servlet 2.3 spec's functionality requirements :-). Aside from downloading the 4.1 source repository, this document will also be visible though the online CVS web access. Sorry, I'm offline at the moment, so I cannot give you a hyperlink, but select the CVSWeb link, module "jakarta-tomcat-4.1", directory "catalina", directory "docs", directory "dev", and file "filters.html". Just in case anyone else is interested: http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat-4.1/catalina/docs/filters.html What I intend to compare is the typical method call sequence of the two approaches, including resource allocation if any, when handling various types requests. From there I hope to point to the relative merits and tradeoffs of each approach. I have fun with this kind of stuff... it harkens back to my old graphics programming days. It's almost always surprising what this stuff will turn up. -Paul Speed I had a Comp Sci prof that made an interesting point -- you only write one real program in your life, and then you spend the rest of your career plagarizing from it :-) Ain't it the truth. One thing that was always fun about graphics programming was that quite often the algorithm that looked least optimal performed the best. Figuring out why is sometimes it's own game. Thanks for the pointer to the doc... it should get me started. -Paul Speed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Fwd: Jakarta PMC Meeting Agenda / Info]
[EMAIL PROTECTED] wrote:
Can you argue about how Valve's single chain of command ( where
authentication, generation, etc are done in a single invoke() ) can
be better than what all other server are doing ( and Apache 2.0
moves to a different level with the flexible HOOK mechanism ?
Actually, this is a discussion I would like to see happen. I
think that I can actually argue for Valves. Admittedly, I know little
about the actual implementations but I am very familiar with the
patterns used in Tomcat 3.x and Tomcat 4.x and I have seen much of the
discussions on this list. However, in other projects I have converted
several architectures using patterns similar to 3.x to be more like the
Valve approach. We did it to shorten development times and improve
developer productivity. Performance wasn't our main goal but in all
but one case performance improved.
What I would like to see is a frank analysis of this topic.
If those "in the know" do not have the time then I will attempt to
do a brief analysis myself in the coming weeks. It will take research
on my part whereas some of you might know the answers off the top of
your head.
What I intend to compare is the typical method call sequence
of the two approaches, including resource allocation if any, when
handling various types requests. From there I hope to point to the
relative merits and tradeoffs of each approach.
I have fun with this kind of stuff... it harkens back to
my old graphics programming days. It's almost always surprising
what this stuff will turn up.
-Paul Speed
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
Geoff Soutter wrote: "Paul Speed" [EMAIL PROTECTED] wrote: [snip] For what it's worth, I think that custom tags are the thing that really saves JSP. On my last project, we were able to encapsulate all logic into a servlet framework and custom tags. (Actually, our framework ended up looking very similar to struts which I think is a very natural evolution of the smart-servlet design.) Depends what you are trying to do. If you want non-java developers to edit the source, then custom tags _do_ save the day. Alternatively, Java in HTML ruins things nicely. IMHO, JSP is just an ASP/CF "me-too"... Not that it means it's not _useful_, it's just not _elegant_. Look at all the spagetti-code ASP and CF sites there are out there. Course now it has the J2EE stamp of approval, how good it actually is becomes irrelevant. Sigh. Yeah, but the nice thing is that it's easy to spot Java code in HTML during a code-review... it just looks ugly. It would be nice if there was a switch on the JSP compiler that specifically disallowed it. Once you've clamped down on the use of Java code inside the JSP's then the developer is forced to use the custom tags. If the custom tags only provide presentation control then you can be fairly sure that no business/application logic is creeping its way into the JSP code. I've always found it funny that the custom tag examples put out by Sun inevitably show how to implement some SQL/JDBC custom tags. It's nice as a comparison to Cold Fusion or PHP, but putting SQL code right into the HTML is the thing that makes most of us who have been doing this for a while cringe. :) I can't think of a better generalized example though. -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [tomat 4.0] running on windows
Remy Maucherat wrote: has anyone actually gotten m5 to startup on win98? i sure can't. I tried with Cygwin, and it didn't work either. The Windows Java exe apparently can't understand a Unix style classpath :( Remy Can you explain what you mean by that statement? I use Unix style classpaths all the time on Windows and was just wondering specifically what the problem is. The only problem I've ever had with cygwin is that pwd Unixizes my path in a way that no normal program can understand, ie: /cygdrive/c/ The make files I use for some of my projects use pwd quite frequently to build paths, etc. and cygwin broke these. I had to make special provisions for a cygwin environment. -Paul Speed
