Repost: SSI invoking CGI fix PATCH
Errr, Anyone care about this? How do I get a patch in the repository? Hello Tom Cats, Currently under Tomcat 4.1.12 SSI normal configuration which invokes a CGI script does not work. The reason for this is pretty obvious: The SSI servelet uses the pathInfo (PATH_INFO) value and calls the request dispatcher for any resources needed. The request dispatcher eats the pathInfo value and the CGI servlet can't find the CGI program, because it relies on pathInfo to tell it where the script is. Or something like that, whatever, you cats probably know better. Anyway, I made minor changes to three files in the current 4.1.12 distro to solve this problem. The strategy is thus: SSI-invoked resources flag the request with an attibute. When CGI servlet finally gets the request dispached, he checks whether SSI servlet invoked the resource via said attribute. If this is the case, he ignores the request.getPathInfo() method in favor of an already-present attribute on the request which already has the PATH_INFO environment value in it. Voila, everything works now. Diff attached. Nick Bauman Software Engineer Cortexity Development 3600 N. Dupont Minneapolis, MN 55412 M: 612-232-7120 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] SSI-CGI fix in Tomcat 4.1.12
Currently under Tomcat 4.1.12 SSI normal configuration which invokes a
CGI script does not work. The reason for this is pretty obvious: The SSI
servelet uses the pathInfo (PATH_INFO) value and calls the request
dispatcher for any resources needed. The request dispatcher eats the
pathInfo value and the CGI servlet can't find the CGI program, because
it relies on pathInfo to tell it where the script is.
I made minor changes to three files in the current 4.1.12 distro
to solve this problem. The strategy is thus: SSI-invoked resources flag
the request with an attibute. When CGI servlet finally gets the request
dispached, he checks whether SSI servlet invoked the resource via said
attribute. If this is the case, he ignores the request.getPathInfo()
method in favor of an already-present attribute on the request which
already has the PATH_INFO environment value in it.
Voila, everything works now. Diffs attached.
Nick Bauman
Software Engineer
Cortexity Development
3600 N. Dupont
Minneapolis, MN
55412
M: 612-232-7120
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
2002-09-23
03:24:20.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
2002-12-03
20:48:00.0 -0600
@@ -290,5 +290,13 @@
public static final String WORK_DIR_ATTR =
javax.servlet.context.tempdir;
-
+/**
+ * The servlet context attribute under which we store a flag used
+ * to mark this request as having been processed by the SSIServlet.
+ * We do this because of the pathInfo mangling happening when using
+ * the CGIServlet in conjunction with the SSI servlet. (value stored
+ * as an object of type String)
+ */
+public static final String SSI_FLAG_ATTR =
+org.apache.catalina.ssi.SSIServlet;
}
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-09-23
03:24:18.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-12-03
20:54:32.0 -0600
@@ -966,8 +966,12 @@
String sCGIName = null;
String[] sCGINames;
-
-sPathInfoOrig = this.pathInfo;
+if(null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
+// invoked by SSIServlet, which eats our req.getPathInfo() data
+sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
+} else {
+sPathInfoOrig = this.pathInfo;
+}
sPathInfoOrig = sPathInfoOrig == null ? : sPathInfoOrig;
sPathTranslatedOrig = req.getPathTranslated();
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
2002-09-23
03:24:18.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
2002-12-03
19:44:06.0 -0600
@@ -64,38 +64,24 @@
package org.apache.catalina.ssi;
+import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
-import java.io.BufferedInputStream;
-import java.io.BufferedReader;
-import java.io.ByteArrayOutputStream;
import java.io.PrintWriter;
-import java.io.Reader;
import java.io.StringWriter;
-import java.io.Writer;
import java.net.URL;
import java.net.URLConnection;
-import java.net.URLDecoder;
-import java.util.ArrayList;
-import java.util.Collection;
import java.util.Date;
-import java.util.Enumeration;
-import java.util.HashMap;
-import java.util.Locale;
-import java.text.SimpleDateFormat;
-import java.util.StringTokenizer;
-import java.util.TimeZone;
-import javax.servlet.RequestDispatcher;
-import javax.servlet.ServletException;
+
import javax.servlet.ServletContext;
-import javax.servlet.ServletOutputStream;
+import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.Globals;
+
/**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
@@ -234,7 +220,7 @@
res.setDateHeader(Expires, (
new java.util.Date()).getTime() + expires.longValue() * 1000
SSI invoking CGI fix PATCH
Hello Tom Cats,
Currently under Tomcat 4.1.12 SSI normal configuration which invokes a
CGI script does not work. The reason for this is pretty obvious: The SSI
servelet uses the pathInfo (PATH_INFO) value and calls the request
dispatcher for any resources needed. The request dispatcher eats the
pathInfo value and the CGI servlet can't find the CGI program, because it
relies on pathInfo to tell it where the script is. Or something like that,
whatever, you cats probably know better.
Anyway, I made minor changes to three files in the current 4.1.12 distro
to solve this problem. The strategy is thus: SSI-invoked resources flag
the request with an attibute. When CGI servlet finally gets the request
dispached, he checks whether SSI servlet invoked the resource via said
attribute. If this is the case, he ignores the request.getPathInfo()
method in favor of an already-present attribute on the request which
already has the PATH_INFO environment value in it.
Voila, everything works now. Diff attached.
Nick Bauman
Software Engineer
Cortexity Development
3600 N. Dupont
Minneapolis, MN
55412
M: 612-232-7120
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
--- jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
2002-09-23 03:24:20.0 -0600
+++ jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
+ 2002-12-03 20:48:00.0 -0600
@@ -290,5 +290,13 @@
public static final String WORK_DIR_ATTR =
javax.servlet.context.tempdir;
-
+ /**
+* The servlet context attribute under which we store a flag used
+* to mark this request as having been processed by the SSIServlet.
+* We do this because of the pathInfo mangling happening when using
+* the CGIServlet in conjunction with the SSI servlet. (value stored
+* as an object of type String)
+*/
+public static final String SSI_FLAG_ATTR =
+org.apache.catalina.ssi.SSIServlet;
}
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-09-23 03:24:18.0 -0600
+++
+jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
+ 2002-12-03 20:54:32.0 -0600
@@ -966,8 +966,12 @@
String sCGIName = null;
String[] sCGINames;
-
-sPathInfoOrig = this.pathInfo;
+if(null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
+ // invoked by SSIServlet, which eats our req.getPathInfo() data
+ sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
+} else {
+sPathInfoOrig = this.pathInfo;
+}
sPathInfoOrig = sPathInfoOrig == null ? : sPathInfoOrig;
sPathTranslatedOrig = req.getPathTranslated();
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
2002-09-23 03:24:18.0 -0600
+++
+jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
+ 2002-12-03 19:44:06.0 -0600
@@ -64,38 +64,24 @@
package org.apache.catalina.ssi;
+import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
-import java.io.BufferedInputStream;
-import java.io.BufferedReader;
-import java.io.ByteArrayOutputStream;
import java.io.PrintWriter;
-import java.io.Reader;
import java.io.StringWriter;
-import java.io.Writer;
import java.net.URL;
import java.net.URLConnection;
-import java.net.URLDecoder;
-import java.util.ArrayList;
-import java.util.Collection;
import java.util.Date;
-import java.util.Enumeration;
-import java.util.HashMap;
-import java.util.Locale;
-import java.text.SimpleDateFormat;
-import java.util.StringTokenizer;
-import java.util.TimeZone;
-import javax.servlet.RequestDispatcher;
-import javax.servlet.ServletException;
+
import javax.servlet.ServletContext;
-import javax.servlet.ServletOutputStream;
+import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.catalina.Globals;
+
/**
* Servlet to process SSI requests within a webpage.
* Mapped to a path from within web.xml.
@@ -234,7 +220,7 @@
res.setDateHeader(Expires
Illustration of Tomcat 4's configuration architecture
To those of you building and working on Tomcat, I have a pictorial view of Tomcat's configuration design, according to my understanding. Could one of you take a moment to verify it? Let me know and I will correct it and offer it to the community in the hopes that it will be useful for documentation purposes. A little background: I decided to do this because it was proving to be rather difficult to get Apache 1.3, Tomcat 4.0.1 and JBoss 2.4.4 running happily together in a sanely-deployable way. I have been using a commercial J2EE solution up until now and the only thing that it has over its Open Source bretheren is documentation. - /\/ -- Nick Bauman Cortexity Development -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Illustration of Tomcat 4's configuration architecture -- woops
DUH, forgot the URL. http://www.cortexity.com/images/tomcat_config.jpg To those of you building and working on Tomcat, I have a pictorial view of Tomcat's configuration design, according to my understanding. Could one of you take a moment to verify it? Let me know and I will correct it and offer it to the community in the hopes that it will be useful for documentation purposes. A little background: I decided to do this because it was proving to be rather difficult to get Apache 1.3, Tomcat 4.0.1 and JBoss 2.4.4 running happily together in a sanely-deployable way. I have been using a commercial J2EE solution up until now and the only thing that it has over its Open Source bretheren is documentation. - /\/ -- Nick Bauman Cortexity Development -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Non-web .jsp templates ?
I've actually done what you describe. After building a half-assed version using JSP, I abandoned it in favor or Velocity. The Velocity version ended up being 1/2 the complexity of the JSP version because of the difficulty in embedding a servlet engine into a component which is using an RMI protocol. (otherwise, talking to your mail templates over a socket using HTTP is pretty lame) It comes down to one very powerful thing Velocity has over JSP: it's completely uncoupled from any servlet technology. Hi, Our team was recently discussing potential usage of .jsp pages as templates for use with automatic mail generation and other automated tasks when the result is not sent via http but stored and/or processed. Are there any (open-source preffered) projects (taglibs?) with similar goals? If not, do you think it's something with enough demand to release it when it's late-beta? The discussed approach was to include a jsp-template inside of a custom tag redirecting it to a specified e-mail address/list on an itermediate (process and forward type) jsp page. Greetings, deacon Marcus -- Nick Bauman Software Engineer 3600 Dupont Minneapolis, MN 55412 Mobile Phone: (612) 232-7120 Home Phone: (612) 522-0165
Re: Taglibs Article
Nick Bauman wrote: As far as mixing presentation logic and business logic together, well, you can do that with Velocity, too. Although it makes you think longer and harder about it. Here's a recent template snippet I wrote. This is something you wouldn't necessarily be proud of doing with Velocity. 8 #foreach( $event in $events ) $yapper = $meeting.getParticipation( ((MeetingEvent)$event).getFromId() ) #if( $repRole.equals($yapper.getRole() ) $repId = $yapper.getParticipantId() font color=$blackb$yapper.getName()/b/font #else font color=$blueb$yapper.getName()/b/font #end #if ( $event.getClass().getName().equals($chatEventType) ) ((com.webhelp.emeeting.events.ChatEvent)$event).getStoredData() br #else if( $event.getClass().getName().equals($urlPushedEventType) ) a href=((com.webhelp.emeeting.events.URLPushedEvent)$event).getStoredData ()((com.webhelp.emeeting.events.URLPushedEvent)$event).getStoredData() /abr #end #end Just out of idle curiousity, why does it look like you are attempting to do a cast with the ((com.webhelp.emeeting.events.URLPushedEvent) $event ) bit? Velocity has no such thing as a cast... - it will introspect and find getStoredData() on it's own... Yeah, I'd discovered that later Very cool! And for fun, can someone translate that into JSP tags to see what it would look like? I can show you the JSP because this thing started as JSP once. Not pretty, but a Java developer would feel at home, thats about all I could say positive about it ;) geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Developing for the web? See http://jakarta.apache.org/velocity/ still climbing up to the shoulders... -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: Taglibs Article
Now, I wonder if I could successfully rekindle a Velocity vs. JSP flamewar ... evil grin ... don't ask me, I'm strictly a servlet guy. Mixing business and presentation logic is exhilirating, kinda like running with scissors or jumping in the pool less than 30 minutes after a meal. - Christopher I'm having a lot of fun with Velocity right now. It has a distinct advantage over JSP in one area for me: it'll run outside of a Servlet Container easily, and very nicely thank you. As far as mixing presentation logic and business logic together, well, you can do that with Velocity, too. Although it makes you think longer and harder about it. Here's a recent template snippet I wrote. This is something you wouldn't necessarily be proud of doing with Velocity. 8 #foreach( $event in $events ) $yapper = $meeting.getParticipation( ((MeetingEvent)$event).getFromId() ) #if( $repRole.equals($yapper.getRole() ) $repId = $yapper.getParticipantId() font color=$blackb$yapper.getName()/b/font #else font color=$blueb$yapper.getName()/b/font #end #if ( $event.getClass().getName().equals($chatEventType) ) ((com.webhelp.emeeting.events.ChatEvent)$event).getStoredData() br #else if( $event.getClass().getName().equals($urlPushedEventType) ) a href=((com.webhelp.emeeting.events.URLPushedEvent)$event).getStoredData()((com.webhelp.emeeting.events.URLPushedEvent)$event).getStoredData()/abr #end #end 8 Although I think I can clean this up a lot using #macro, it shows how you can use the dark side of the force even with a great tool like Velocity. -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: Taglibs Article
Well, you're exposing an Event API for this application, for starters. And, ahem, getRole() smells like some serious business logic, eh? On Fri, 25 May 2001, Nick Bauman wrote: 8 #foreach( $event in $events ) $yapper = $meeting.getParticipation( ((MeetingEvent)$event).getFromId() ) #if( $repRole.equals($yapper.getRole() ) $repId = $yapper.getParticipantId() font color=$blackb$yapper.getName()/b/font #else font color=$blueb$yapper.getName()/b/font #end #if ( $event.getClass().getName().equals($chatEventType) ) ((com.webhelp.emeeting.events.ChatEvent)$event).getStoredData() br #else if( $event.getClass().getName().equals($urlPushedEventType) ) a href=((com.webhelp.emeeting.events.URLPushedEvent)$event).getStoredData()((com.webhelp.emeeting.events.URLPushedEvent)$event).getStoredData()/abr #end #end 8 where's the business logic? -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: Jasper performance
Yea, JSP protects you from memory leaks and System Crashes. Yea Right. Oh yea, and ASP is lacking customizable tags...as if customizable tags is a good thing Jihad! If we're going to open that debate, then why use Java at all? After all, the computer scientist will tell you with C/C++, you are coding to an unsafe low-level substrate (machine code). With Java, you are coding to a safe high-level substrate (JVM bytecode). Isn't Java therefore just better? But then I could write perfect Java code yet if I have a problem with the JVM, I will crash my safe substrate. I admire the quixotic crusader in you Jon, really I do: The world needs more grail seekers. But you can cease insisting on magic programming bullets for the time being. And I think most people on this list will tell you ASP stands for A Slow Page. JSP sucks. -jon -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: Jasper performance
I, for one, would be very interested in making it easy/possible to uncouple Jasper from the servlet container itself. The question I have is How much of a scaffolding is required to use Jasper purely as a template engine without the baggage of the servlet container per se (or at worst, by being able to call the _jspservice method with a parameters of (HttpServletRequest, HttpServletResponse) from within an application instead of over the wire with http). Is there anyone who has done this already? Jasper performance has already been identified as an area needing improvement. Discussions and work on this has already started in the main tomcat branch in CVS jakarta-tomcat/proposals/jasper34, but this may be moving to the CVS repository jakarta-tomcat-jasper. This work just started recently, I don't know when it will be ready. It will take few months - it's not that easy. We already added tag pooling in tomcat3.3, and that have a significant effect on performance if you are using tags - but that's just the beginning. The first step is to reorganize the code. Then we'll try to make the code generator more customizable ( probably by using XSLT for some of the operations ). The real performance enhancement will come when we start tunning the generated code - there are many ideas around, but we need the refactoring first. BTW, jasper will share most of the code for the 1.1 and 1.2 APIs, so all enhancements will be available in both 3.x and 4.x ( and other containers as well ). If you have ideas, code or opinions - please get involved, we need you :-) Costin Rickard Öberg wrote: Hi! We are using Tomcat/JBoss and are pleased with the actual functionality. What is killing us right now is the performance of the code generated by Jasper, especially when using taglibs in complex ways. The generated code is way too unoptimized. So, if this has not been asked before (in which case a RTFA is ok, although I've looked already), my question is: When will Jasper be rewritten? Are there any such projects underway now? Have there been any discussions about this yet? Am I the only one seeing this problem, or are more people concernced about it? Thanks, Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
RE: [PROPOSAL AJP14] AJP13 Evolution
2 things: The system is aimed to be simple, we don't want SSH/SSL here but just a basic 'protected' login. and that you can bind the socket to 127.0.0.1:PORT instead of *:PORT through a config change. This level of security would cover most of the installations and when someone requires an additional level of security or interface to other security mechanisms, that could be added later. We can add native SSH tunneling for example using openssh. You could do that already with no modifications to the ajp by using port forwarded SSH tunneling. Heck, you could do it with STunnel if you want to use RSA/SSL instead of SSH also without modifications to ajp. -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: Nagoya.apache.org
A while ago I tried to run bugzilla in a chroot jail using thttpd (apache no longer supports chroot'ing, it seems). I got it somewhat working, but I gave up and went to bugrat, for better or worse. I think if you can chroot (and run unprivledged) bugzilla, this greatly minimizes any security implications you've seen. Without chrooting and running as an unprivledged user, bugzilla is not only insecure, it's insecurable. on 5/3/01 11:42 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/ http://nagoya.apache.org/bugzilla/globals.pl When is someone going to secure that box? This is really pitiful that this has been open like this for this long now and on top of it, it is running an old version of bugzilla (2.10 and 2.12 is latest). There have been security advisories regarding the recent holes discovered in Bugzilla and no one managing nagoya has taken care of the situation. I don't think we (the ASF) should give out apache.org domains to boxes that are not being managed properly. I also don't think that we should rely on a box as our primary issue tracking system if security is also not going to be taken seriously. thanks, -jon -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
RE: Tabs vs. spaces (was: cvs commit: blah blah blah)
This issue would be moot if you frontended your CVS checkins with a beautifier. Here's an edited version of a comment on tabs and spaces I sent to our development team that might be useful. ---cut--- -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
RE: Tabs vs. spaces (was: cvs commit: blah blah blah)
My company is, for a team of about 15+ people. We use JIndent on .java files. Works great. If it's doing damage, then it misconfigured. True; not using a beautifier or CVS (now we're using Perforce). I find that beautifiers do more damage than good, but I'm happy to be enlightened; is anyone actually doing this in practice? -tom -Original Message- From: Nick Bauman [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 12, 2001 9:34 AM To: [EMAIL PROTECTED] Subject: RE: Tabs vs. spaces (was: cvs commit: blah blah blah) This issue would be moot if you frontended your CVS checkins with a beautifier. Here's an edited version of a comment on tabs and spaces I sent to our development team that might be useful. ---cut--- -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406 -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: cvs commit:
Yeah, I don't see what the big wup is about formatting. We run a beautifier
against all commits to CVS. Works great and no more "format" wars.
on 4/10/01 6:46 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote:
+
/**
+ * Close any database connection that is currently open.
+ */
+protected void close() {
+
+// Do nothing if the database connection is already closed +
if (dbConnection == null)
+return;
+
+// Close our prepared statements (if any)
+try {
+preparedCredentials.close();
+} catch (Throwable f) {
+;
+}
+try {
+preparedRoles.close();
+} catch (Throwable f) {
+;
+}
+
+// Close this database connection, and log any errors
+try {
+dbConnection.close();
+} catch (SQLException e) {
+log(sm.getString("jdbcRealm.close"), e); // Just log it
here +}
+
+// Release resources associated with the closed connection +
dbConnection = null;
+preparedCredentials = null;
+preparedRoles = null;
+
+}
Craig, does this mean you (finally) aren't using tabs anymore? :-)
Craig, does this mean you (finally) aren't using tabs anymore? :-)
-jon
--
Nick Bauman
Software Developer
3023 Lynn #22
Minneapolis, MN
55416
Mobile Phone: (612) 810-7406
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. An alternative view! On 4 Apr, Brad Cox wrote: At 11:24 AM -0700 04/04/2001, Jon Stevens wrote: I love the article title: "Just say no to JSP" I am really sorry to see folks coming on this list, and also publishing to the general web articles deriding JSP and tomcat in particular. I have apache-1.3.19 with tomcat-3.2.2b running behind it just fine using mod_jk. The application running is an apache soap server This is on a redhat 6.2 box. I also have tomcat-4.0 running on port 7070 at the same time where I am doing development on a secure email application. I have moved my email app back and forth between TC3.2 and TC4.0 with no problems. I just drop the war file in the webapps directory and tomcat does the rest. I do have all the latest jar files from SUNW, and jakarta-apache. So I don't know what the problems could be. My only complaints would be not enough debug tools around to be able to single step through new code when you are having problems, but I consider that minor at this point, given where the tomcat development cycle is. I think the tomcat developers for all their good work. =eas= -- . | | | | - | | * +---+ | | I'd Rather Be Sailing A Laser | | -- +---+ | 83345 | | --- | |[EMAIL PROTECTED] |-O--- |/w-| ..|=| I| | ~~~ -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Jason, Yes, and the way I've seen people solve this issue is to make each server constantly replicate its sessions to another server so that any session's state is stored in two servers (not just one). For example, if you've got four servers, A, B, C, and D, you configure A to replicate to B, B to replicate to C, C to replicate to D, and D to replicate to A. Then the "composite ID" would contain the primary server tag, secondary server tag, and the session ID, like: A:B:sessionXXX. So, if server A went down, the load balancer could still get session info from server B, and at the same time let server D know that A is down and to replicate to B until further notice. Nh. This is once again only making sure a majority of the sessions are saved in a rotation. A lot of work for very little real fault tolerance. Also I think your english up there indicates a solution that causes tremendous hysterysis amongst the servers. This also works when each server replicates sessions to more than one backup server so that you've got even higher fault tolerance (but you'll probably never need that level of fault tolerance). Now you may have something: a seperate, parallel, session cluster. -- Jason Brittain -- Nick Bauman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FW: [advanced-servlets] Session Load Balancing (was: To avoid
Pier, If the next request from that client is routed to server Y, then server Y will get a request with that same composite ID of "serverX:sessionPPP". This tells server Y that the first thing it needs to do is get the canonical version of Session sessionPPP from server X. (The exact method for this may vary, but suffice to say it will not involve spawning Threads from Servlets. :-) In the response The only problem with this is you have N servers in a rotation (sprayed or DNS round-robin) and one goes down, you lose 1/N sessions. Some people think that if you are going to bother with session load balancing / distribution at all, why not try and ensure all the sessions are safe, not just a majority. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Some benchmarks
Costin, Why in the WORLD should anyone be serving static html from tomcat through the connector from Apache? Working to improve performance of this kind of behavior, in my mind, is a total sillyness. A waste of your time. They should instead configure Apache to serve html itself and only pass servlet and jsp requests to the Container. If you are talking about improving the speed of the proto and using this as a cross-section of the protocol's overhead, then I understand, I guess. Could you clear this up for me? Thanks At c=10: 3.3.m1 Ajp12 (956/338) 3.3.m1 Ajp13 (966/390) At c=100: 3.3.m1 Ajp12 (920/343) 3.3.m1 Ajp13 (929/393) Not good I guess we can focus on ajp13 and do few changes, fixing both doesn't make sense. Mea culpa, I did a lot of tests/optimizations on standalone but I didn't reproduced them on the ajp side. I've been a bit lazy lately, the profiles are not ready yet and there are few bugs I'm draging... The good news is that it shouldn't be difficult to at least double the performance for ajp13 in few days, I expect it to be due to GC and the changes are easy to do ( I already done them in the Http10 side ). I guess I need few vacation days :-) Costin -- Nick Bauman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
BugRat temporarily going down
Znutar.cortexity.com (home of Jakarta BugRat) will be temporarily off the net tonight. Now that a nagoya.apache.org (home of Jakarta BugZilla) is in place and BugRat is only used for historical purposes, I think it's a good time to do the upgrades on the system I had planned a while back: I'm converting the IDE drives to SCSI and adding 128 MB of ram. -- Nick Bauman Software Developer 3023 Lynn #22 Minneapolis, MN 55416 Mobile Phone: (612) 810-7406 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/coreStandardContext.java StandardHost.java
On 20 Jan 2001 [EMAIL PROTECTED] wrote: - Add a new "unpackWARs" flag in the StandardHost : if true, the host will deploy WARs as before. If false, the WARs found in the host path won't be unpacked and the WARDirContext will be used. Very very cool. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugRat Report #804 has been filed.
Hans, can you stick this tip in BugRat as a comment and close the bug out? On Fri, 19 Jan 2001, Hans Bergsten wrote: Note that you can use single quotes around the attribute value so you don't have to escape double quotes in the value. Hans -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Craig, These design goals are AWESOME. It makes much more sense to do this way. However, I _did_ do this as you mentioned: I have *.jsp and *.j mapped to specific servlets in my ROOT/WEB-INF/web.xml and all I got was the output of index.jsp as something Netscape had to download. telnetting to the webserver port revealed that the index.jsp was being served by Apache, not Catalina. I'll mess around with it this weekend and see if I can get it to work "as advertised" and report back my results, but I have a couple of guys waiting on a servlet container that works with our *.j framework to test today, so I'm temporarily falling back to 3.2. I'm really happy that this approach is being followed as it's much more (ultimately) intuitive than the way it's done in 3.2 because it's simpler. Thanks again, -Nick On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: On Fri, 19 Jan 2001, Craig R. McClanahan wrote: Nick Bauman wrote: Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? The design goals for mod_webapp say that it should respect web.xml mappings -- in other words, if you added a servlet-mapping entry for "*.foo" to a particular servlet, then that is what would happen at runtime. I totally do not understand this! I'm dense or something: How does Apache / DSO* know about something in the web.xml? This is the key architectural difference between mod_webapp and the current generation of connectors. When mod_webapp establishes its initial connection from Apache to Tomcat, the configuration information (extracted from the property getters of the internal Context object) is sent back to the connector in order to configure everything about this particular webapp. From the sysadmin perspective, this means we can forget all about having to configure things twice (once in httpd.conf and once in web.xml). It's also a requirement of the 2.3 spec -- if we create a "servlet container" using Apache+Tomcat together, it (the combination) must still obey all the servlet spec requirements, including respecting things in web.xml. If I grok you, this still relies on having /foo mapped to the servlet container in Apache. I'm in a situation where Apache's DocumentRoot _is the same as_ the top level of the WAR, but I want Apache to serve the *.html and *.gif and *.jpg and *.png and I want Tomcat to only do the *jsp and a special mapping (in this case *.j). Then what you'd want is to configure the ROOT webapp to have a context base equal to your Apache document root. If you want things mapped to servlets, just do them with servlet-mapping entries *exactly* like you would for Tomcat stand-alone. As I mentioned earlier, the connector takes over the "default servlet" mapping, so it will handle everything that is *not* explicitly mapped to a servlet (i.e. all the static files). Again, this is all the design goals -- I have not tested the current implementation to see if it achieves these goals yet. In particular, I recall seeing bug reports about mapping the ROOT context. The primary difference between Tomcat 4.0 stand alone and Tomcat 4.0 behind Apache is the mapping for the "default" servlet. In the stand-alone case, this is mapped to the Tomcat servlet that serves static resources. In the connected case, they would be served by Apache. I don't see how this works in my case. I'm being dense, I think. If you were running Tomcat stand-alone, you would accomplish the goal of mapping *.j files to a particular servlet like this (in your webapp's web.xml file): servlet servlet-nameMyServlet/servlet-name servlet-classcom.mycompany.mypackage.MyServlet/servlet-class /servlet servlet-mapping servlet-nameMyServlet/servlet-mapping url-pattern*.j/url-pattern /servlet-mapping and this rule would get applied to all incoming requests -- a request for "foo.j" would be sent to your servlet, while a request for "foo.html" would be handled by the default file-serving servlet. In Tomcat4+Apache, you do *exactly* the same thing. The only difference at runtime is that Apache becomes the "default file-serving servlet" instead of the servlet inside Tomcat. Does that help? At any rate, this is the theory -- Pier can comment on current practice. I know he's working on a bunch of bug fixes for the originally reported problems. Craig I would like to have it work in my case, but in order for me to help make it happen, I need to understand the goal, which I don't understand. If you or Pier can nurse me along a bit, I will work on making it happen in my case (I do know C) and give it
Catalina + Apache
Hello Jakarta Tribe, We are targeting Tomcat 4.0 for a project to be released within 30 days. We currently have an app in production at Exodus in Chicago that utilizes many megabits of throughput and runs on multiple webservers that are load balanced using TC 3.1 and Apache 1.3. This is a new release of this app. I have some questions: 1) If we are choosing to go with 4.0, should we also be taking a look at Apache 2.0? How far has the integration come on that front? 2) Using the mod_webapp.so, do we need to specify a "Tomcat Standalone" service with our ROOT context, or is the "Tomcat-Apache" all we need (and we should define the ROOT context int there) Thanks, -Nick Bauman (The guy running BugRat for Jakarta) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Catalina + Apache
Uhhh, I just realized something With TC 3x, you could map an extension from Apache to the servlet engine with an AddHandler directive. I see nothing like this for TC4. Can someone enlighten me? On Thu, 18 Jan 2001, Nick Bauman wrote: Hello Jakarta Tribe, We are targeting Tomcat 4.0 for a project to be released within 30 days. We currently have an app in production at Exodus in Chicago that utilizes many megabits of throughput and runs on multiple webservers that are load balanced using TC 3.1 and Apache 1.3. This is a new release of this app. I have some questions: 1) If we are choosing to go with 4.0, should we also be taking a look at Apache 2.0? How far has the integration come on that front? 2) Using the mod_webapp.so, do we need to specify a "Tomcat Standalone" service with our ROOT context, or is the "Tomcat-Apache" all we need (and we should define the ROOT context int there) Thanks, -Nick Bauman (The guy running BugRat for Jakarta) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: BugRat Report #758 was closed (apparently by: Ignacio Ortega)
758 has been reopened. On Sat, 13 Jan 2001, Ignacio J. Ortega wrote: Upsss, this was closed by mistake, sorry Nick can you reopen it, please ??? TIA Saludos , Ignacio J. Ortega -Mensaje original- De: BugRat Mail System [mailto:[EMAIL PROTECTED]] Enviado el: sábado 13 de enero de 2001 2:05 Para: Z_Tomcat Alias Asunto: BugRat Report #758 was closed (apparently by: Ignacio Ortega) Report #758 was closed by Person #0 Synopsis: HTTP POST incorrect behavior (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat can be shutdown by ANYONE.
Permissions 500 and ownership as nobody on the shutdown script should do it. In an rc script you can change ownshership before booting the server like so: echo "/usr/local/jakarta-tomcat-3.2/bin/startup.sh " | su nobody Works dandy over here. On Fri, 5 Jan 2001 [EMAIL PROTECTED] wrote: I have tried to run Tomcat 3.2.1 as nobody then on another shell login as my id ( eg barrow ), and run TOMCAT_HOME/bin/shutdown.sh. I can successfully bring tomcat. I also tried to run Tomcat 3.2.1 as root and I can also shutdown Tomcat 3.2.1 as my id ( eg. barrow ). Unless I did my configuration wrong; otherwise, anyone who have access to my Linux box will be above to shutdown Tomcat without any notice.. PS: my id - bhkwan, doesn't have super user privilege. It is just a regular user account. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat can be shutdown by ANYONE.
On Fri, 5 Jan 2001, Jon Stevens wrote: on 1/5/2001 7:00 PM, "Nick Bauman" [EMAIL PROTECTED] wrote: Permissions 500 and ownership as nobody on the shutdown script should do it. In an rc script you can change ownshership before booting the server like so: echo "/usr/local/jakarta-tomcat-3.2/bin/startup.sh " | su nobody Works dandy over here. So, what prevents someone from executing their own copy of the shutdown script? Nothing! =) -jon -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Session Serialize code
Matt, since they are considering a threadpooler, too, you might also want to share your Object and Thread pooling techniques you've done in the past. The design alone is worth considering it over other techniques. (Matthew has a pooling demo using Object.clone(), which is also very fast and simple) -Nick On Fri, 29 Dec 2000, Matthew Dornquast wrote: Hi Guys, I worked quite a bit with apache serialization code a several months back on various VM's speeding it up. I think I have several observations that I hope you'll consider before using the code I just saw fly by on the list. Basically, I'm a proponent of using externalizable for the session object. My tests show the objects are smaller and less resources are required to serialize/deserialize the object. Use the strategy in class TestObject_D and you'll serialize objects in less time with less storage. The simple proof of the idea is in the attached file SerialDemo1.java. Here you'll find your basic contendors for the "I'm best way to serialize sessions" contest: TestObject_A is your standard no frills serializable object. What most people do. What 3.1 did. TestObject_B is what happen's when you attempt to speed things up a bit. (Like the code I just saw on mailing list) TestObject_C is shows how String writing can be made better. (HUGE difference with JDK 1.1, less for 1.2/1.3) TestObject_D shows the power of fully managing the serialization process. Test results on a couple of platforms: Results of SerialDemo1.java when run on Pentium II 450mhz w/Linux IBM'S JDK: Test results for test.TestObject_A: Total time required- 4540, size of pickled object:99 Test results for test.TestObject_B: Total time required- 2743, size of pickled object:100 Test results for test.TestObject_C: Total time required- 2699, size of pickled object:101 Test results for test.TestObject_D: Total time required- 1755, size of pickled object:70 Results of SerialDemo1.java when run on 600mhz celery laptop in JBuilder's JDK 1.3: Test results for test.TestObject_A: Total time required- 1763, size of pickled object:99 Test results for test.TestObject_B: Total time required- 1512, size of pickled object:100 Test results for test.TestObject_C: Total time required- 1412, size of pickled object:101 Test results for test.TestObject_D: Total time required- 1012, size of pickled object:70 -- Now, if you're on board with the approach of TestObject_D. Take a look at a class I wrote last summer. It's called SerializationDemo.java. This is a full blown implementation/rewrite of the serialization process for sessions. (Sorry about the name, I didn't have time to change this class.) It provide custom optimizations for all the popular data types that might occur in a session and can be easily extended for custom types. The class is called MattWay() (Again-- sorry about the name, this was for my own tests) and is intended to serve as an example of how to fully manage the serialization/deserialization of all the stuff a session might have in it. Anyway, use this method, and you've got lean mean serialized objects that take up the least amount of space possible and have the lowest overhead to serialize/deserialize. Warm regards, -Matthew PS Test results for SerializationDemo.java on a 450 mhz pentinum using jdk1.3: Test=test.ApacheWay, testTime=34238, testSize=5021 Test=test.MattWay, testTime=12830, testSize=2351 Serialization peformance summary=166.85893% faster Size peformance summary=2670 bytes smaller jdk 1.1: Test=test.ApacheWay, testTime=33992, testSize=5037 Test=test.MattWay, testTime=11785, testSize=2336 Serialization peformance summary=188.43446% faster Size peformance summary=2701 bytes smaller -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugRat access
I give people who are accepted committers to Jakarta admin access to BugRat. On Wed, 27 Dec 2000, Marc Saegesser wrote: I need to mark a couple BugRat items as fixed but I don't have a login for the BugRat system. Who do I need to contact to get an account created? Thanks. -- Nicolaus Bauman Software Engineer Simplexity Systems
Re: TC 4.0 vs. TC 3.x and division of labor
Jon, I defend your right to an opinion. Now will you please voluntarily quit this? I'm asking you, amigo, please don't put out fire with gasoline. It's not condusive to anything. Have some fraternity, brutha! \n On Wed, 27 Dec 2000, Jon Stevens wrote: on 12/27/2000 12:59 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Nacho and Larry and Henri did most of the hard work in maintaining 3.2, and it is a _team_ effort. Sam acted as a release manager - doing build after build, as he was supposed to do. Tomcat 3.2 is not _my_ product, but _our_ product, and I think _we_ did a good job overall. I agree. I'm not disputing that. I wrote _a_lot__ of the code that went into 3.2, and I did more work than you can imagine, Jon. I did that even if I had a job that is not tomcat, but xml-xalan. In fact, you did some of that work during your day time job. :-) After 3.2 was frozen I had far more work than I could handle with xalan and jaxp ( thanks to Scott for helping me so much ), and the little free time I got was put into finishing what I started - the refactoring of tomcat3, making it _elegant_ and _fast_ .. Actually, you did that before 3.2 was frozen, didn't you? I remember an email thread asking why work was starting on 3.3 when 3.2 wasn't even done yet. In any case - this is not about me, but about tomcat. I do my best to improve tomcat, if that's not enough for you - I'm sorry. Tomcat 3.x or 4.x? -jon
[BUG TRACKING] -- Bogus reports: let's get 'em closed before 2001
Hello Jakarta Horde, There are A LOT of bug reports in the Jakarta Bug Tracking system, many of them are not bugs, but in fact user and programmer errors cleverly disguised as bugs. (This is similar to the way I am not an actual programmer, but instead a strategically shaved chimpanzee! No, really!) Please let me know if you have ever filed a report from what you thought was a bug that turned out to be something tedious that you overlooked. Give me the bug report ID of the report you filed. If you can't remember the ID, give me as much information as you can and I can look it up without killing the database. Thanks, -Nick -- Nicolaus Bauman Software Engineer (member, ASPCA, since 1976)
Re: SimpleMapper1 ???
Okay, thanks for the clarification. Not sure I understand why it wasn't just merged into SimpleMapper, but maybe in the rush to release things get dog-eared sometimes. On Wed, 20 Dec 2000, craig mcclanahan wrote: Nick Bauman wrote: In TC 3.2 there is, in the default server.xml, a RequestInterceptor called SimpleMapper1. In TC 3.1, it was called ISmpleMapper. Why is this? Is this an interim thing? It's not that big of a deal, it just seems kinda dog-eared, that's all. Thanks, Nick SimpleMapper1 was someone's optimization of the original SimpleMapper algorithm, submitted as a separate interceptor so that someone could configure back to the original one if there were problems with the new one. In Tomcat 4.0, mapping has been generalized so you can do it at the Engine, Host, or Context levels -- the default implementations go by incredibly imaginative :-) names like StandardContextMapper. Craig
RE: [MY_OPINION] Tomcat 3.x
On Tue, 19 Dec 2000, GOMEZ Henri wrote: Look at the bugs in BugRat. The ones coming in for 4.0 are getting linked, documented and closed faster than the ones coming in for 3.x. The bugs for 4.0 are fewer than the ones coming in for 3.x. Shit, I think we've even got some 3.0's in there that haven't been dealt with! I'm sorry to say that the last time (before 3.2.1 release) I tried to use BugRats to get the list of open bugs related to mod_jk/ajp13, I received SQL error ! I won't defend BugRat. It was written for JServ 1.0 and has a lot of problems, not the least of which is it's SQL. But it's better than nothing. So I've commited the patch and don't closed the bug in BugRats (ajp13 + multiples cookies). I'll close it for you then. Can you give me the ID number in question? As far as those of you committing to the 3.x branch today, think about this: Your efforts are sorely needed in the 4.0 tree, right here, right now, today. I have read the code in the 3.x tree. It's shaping up nicely, true, but after reading 3.1 for about 2 days, I got so depressed about the project I thought I was going to blow my head off. To find even where the request comes in I found I had to grep for a "ServerSocket" and drill from there! When I look at 4.0, I can actually READ that code and understand it. The code in 3.3 tree is much more cleaner than in 3.1. Another point is that many others I saw the TC 4.0 really as a Sun Products since all of the core commiters are paid by Sun and spent their many of their WORK TIME on this project. I agreed with the first part of that paragraph; 3.3 is better than 3.1, but the next part of the paragraph, Costin's, et al, heroic efforts aside, is simply not true. Quoting Sam Ruby: "Tomcat 3.0 was clearly a Sun project. Most of the design discussions were held in conference rooms in Sun. The release was made with virtually no prior discussion on the mailing list (remember sideswiped?)." And going back to the original reason I posted to this thread, Quoting Jon Stevens: "One thing that you are all not remembering or even realize is that Catalina was originally going to be JServ 2.0. If Sun had never given us the source code to Tomcat, then you would have been using Catalina anyway." -- Nicolaus Bauman
Re: [MY_OPINION] Tomcat 3.x
On Mon, 18 Dec 2000, Jon Stevens wrote: p.s. One thing that you are all not remembering or even realize is that Catalina was originally going to be JServ 2.0. If Sun had never given us the source code to Tomcat, then you would have been using Catalina anyway. I hope EVERYONE takes what Jon (oddly, so offhandedly) put in the PS to heart right now. This, gentlemen, is the record of history; and as far as I'm concerned, the final word on this thread. Look at the bugs in BugRat. The ones coming in for 4.0 are getting linked, documented and closed faster than the ones coming in for 3.x. The bugs for 4.0 are fewer than the ones coming in for 3.x. Shit, I think we've even got some 3.0's in there that haven't been dealt with! As far as those of you committing to the 3.x branch today, think about this: Your efforts are sorely needed in the 4.0 tree, right here, right now, today. I have read the code in the 3.x tree. It's shaping up nicely, true, but after reading 3.1 for about 2 days, I got so depressed about the project I thought I was going to blow my head off. To find even where the request comes in I found I had to grep for a "ServerSocket" and drill from there! When I look at 4.0, I can actually READ that code and understand it. There's a lot more to writing code whose source was meant to be publically consumed that is not evident in the writing of the 3.x tree. In short, 4.0 is the right code for the right project at the right time. -jon -- Nicolaus Bauman (The guy who runs BugRat for Jakarta)
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
On Mon, 11 Dec 2000, Craig R. McClanahan wrote: Tomcat 3.2 final has the following security vulnerabilities that have subsequently been fixed in the CVS repository: * A URL like "http://localhost:8080/examples//WEB-INF/web.xml" can expose sensitive information (note the double slash after "examples"). * The "Show Source" custom tag used to display JSP source code can be used to expose sensitive information in WEB-INF. BTW: I think it should be made clear this is only an issue if you are not using a webserver, like apache, in front of the Container. A properly configured apache renders these vulnerabilites moot. -Nick
Re: BugRat Report #556 has been filed.
Can you give us more information? Do you see the JVM growing and no GC happening? Did you see this behavior with earlier versions of tomcat? Other servlet container implementations? On Fri, 8 Dec 2000, BugRat Mail System wrote: Bug report #556 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/556 REPORT #556 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: JDK 1.3 Operating System: Windows 2000 Professional OS Release: 5.00.2195 SP 1 Platform: Win2K Synopsis: Out of memory error Description: After a few request, random OutOfMemoryError(s) occur within Tomcat framework (detailled traces shown below) D:\tomcat\bincall D:\tomcat\bin\tomcat.bat stop Including all jars in D:\tomcat\lib in your CLASSPATH. Using CLASSPATH: D:\tomcat\classes;D:\classes;D:\tomcat\lib\ant.jar;D:\tomcat\li b\jasper.jar;D:\tomcat\lib\jaxp.jar;D:\tomcat\lib\parser.jar;D:\tomcat\lib\servl et.jar;D:\tomcat\lib\webserver.jar;D:\lib\Acme.jar;D:\lib\activation.jar;D:\lib\ gnujsp10.jar;D:\lib\HTTPClient.jar;D:\lib\j2ee.jar;D:\lib\jai_codec.jar;D:\lib\j ai_core.jar;D:\lib\JimiProClasses.jar;D:\lib\log4j-full.jar;D:\lib\mail.jar;D:\l ib\Opta2000.jar;D:\lib\oreilly.jar;D:\lib\syslog.jar;D:\lib\TIMInfrastructure.ja r;C:\java\jdk13\lib\tools.jar Stop tomcat Deleted file - D:\tomcat\work\localhost_8080\_0002fcompany_0002fprocess_0002ejsp process.class Deleted file - D:\tomcat\work\localhost_8080\_0002finc_0002fcommon_0002fselect_0 002fmake_0002f_00034_0002ejsp4.class Deleted file - D:\tomcat\work\localhost_8080\_0002finc_0002fen_0002flogin_0002ft ext_0002ejsptext.class Deleted file - D:\tomcat\work\localhost_8080\_0002finc_0002fen_0002foptions_0002 f_00034_0002ejsp4.class Deleted file - D:\tomcat\work\localhost_8080\_0002finc_0002fen_0002fselect_0002f subcategory_0002f_00031_0002ejsp1.class Deleted file - D:\tomcat\work\localhost_8080\_0002finc_0002fen_0002fselect_0002f subsubcategory_0002f_00034_0002ejsp4.class Deleted file - D:\tomcat\work\localhost_8080\_0002finventory_0002fcatprocess_000 2ejspcatprocess.class Deleted file - D:\tomcat\work\localhost_8080\_0002finventory_0002fextraprocess_0 002ejspextraprocess.class Deleted file - D:\tomcat\work\localhost_8080\_0002finventory_0002fprocess_0002ej spprocess.class Deleted file - D:\tomcat\work\localhost_8080\_0002flogin_0002fprocess_0002ejsppr ocess.class Including all jars in D:\tomcat\lib in your CLASSPATH. Using CLASSPATH: D:\tomcat\classes;D:\classes;D:\tomcat\lib\ant.jar;D:\tomcat\li b\jasper.jar;D:\tomcat\lib\jaxp.jar;D:\tomcat\lib\parser.jar;D:\tomcat\lib\servl et.jar;D:\tomcat\lib\webserver.jar;D:\lib\Acme.jar;D:\lib\activation.jar;D:\lib\ gnujsp10.jar;D:\lib\HTTPClient.jar;D:\lib\j2ee.jar;D:\lib\jai_codec.jar;D:\lib\j ai_core.jar;D:\lib\JimiProClasses.jar;D:\lib\log4j-full.jar;D:\lib\mail.jar;D:\l ib\Opta2000.jar;D:\lib\oreilly.jar;D:\lib\syslog.jar;D:\lib\TIMInfrastructure.ja r;C:\java\jdk13\lib\tools.jar 2000-12-08 04:29:09 - ContextManager: Adding context Ctx( /examples ) 2000-12-08 04:29:09 - ContextManager: Adding context Ctx( /admin ) 2000-12-08 04:29:09 - ContextManager: Adding context Ctx( ) Starting tomcat. Check logs/tomcat.log for error messages 2000-12-08 04:29:09 - ContextManager: Adding context Ctx( /test ) 2000-12-08 04:29:10 - PoolTcpConnector: Starting HttpConnectionHandler on 8080 2000-12-08 04:29:10 - PoolTcpConnector: Starting Ajp12ConnectionHandler on 8007 MTLInitializer: loading "file:/D:/classes/mtl.config.properties" MTLInitializer: configuring System properties... MTLInitializer: configuring Debug properties... MTLInitializer: Debug mode is ON MTLInitializer: configuring Resource... MTLInitializer: already configured ! 2000-12-08 04:30:45 - Ctx( ): 400 R( /) null 2000-12-08 04:30:47 - Ctx( ): IOException in: R( + /js/selection.js + null) Co nnection aborted by peer: socket write error 2000-12-08 04:30:47 - Ctx( ): IOException in: R( + /js/validation.js + null) C onnection aborted by peer: socket write error 2000-12-08 05:09:08 - Ctx( ): Exception in: R( + /showroom/process.jsp + null) - javax.servlet.ServletException at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:399) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:4 04) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372 ) at org.apache.tomcat.core.ContextManager.internalService(ContextManager. java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743 ) at
Re: Improvement to Bugrat ?
When? When someone edits a bug? When someone closes a bug? When someone links a report? When someone adds a comment? Also, the subject lines are already pretty long right now. Adding more will start to compound the problem you are trying to solve, IMO. If you'd like to change bugrat yourself, the code is on the website: http://znutar.cortexity.com/px/cvsweb.cgi/ Nothing's stoppin' yah from pokin' around and improving it. However, I've tried to get a couple hours to look at why the workarounds and how to reproduce sections don't consistently display, but the code is so raviolied (5000 lines of code in a class, without a single line of Javadoc) I lose the thread in the 15-30 minutes I have time for looking at it. I think fixing these bugs and imroving the search capabilites would be of greater benifit that lengthing the subject line. -Nick On Thu, 7 Dec 2000, Arieh Markel wrote: I am wondering how difficult would be to change bugrat so that the synopsis (or part of it) appears on the mail subject line. Arieh -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key) -- Nicolaus Bauman Software Engineer Simplexity Systems
Re: [BUG TRACKING] change to jakarta.apache.org
On Sat, 2 Dec 2000, Craig R. McClanahan wrote: Fixed. I added the slash on the link for the viewer as well, and it seems to work OK. Cool Craig PS: You might want to upgrade Tomcat to at least 3.2 :-) That's what I did: that's what got the whole mess started! BugRat is running with TC 3.2. I tried running it with 4.0 M4 but I lost confidence somewhere down the line and gave up and went back to 3.2. -Nick
Re: Bugrat down/broken?
OOoops. Sorry. It's fixed now. (forgot to put activation in the TC classpath) On Tue, 28 Nov 2000, Brian Vetter wrote: I tried submitting a new bug to Bugrat this afternoon. I get the following error: Error: 500 Location: /BugRatReport/PostReport Internal Servlet Error: java.lang.NoClassDefFoundError: javax/activation/DataSource at org.gjt.bugrat.servlet.BugRatReport.processReportPOST(Compiled Code) at org.gjt.bugrat.servlet.BugRatReport.doPost(Compiled Code) at javax.servlet.http.HttpServlet.service(Compiled Code) at javax.servlet.http.HttpServlet.service(Compiled Code) at org.apache.tomcat.core.ServletWrapper.doService(Compiled Code) at org.apache.tomcat.core.Handler.service(Compiled Code) at org.apache.tomcat.core.ServletWrapper.service(Compiled Code) at org.apache.tomcat.core.ContextManager.internalService(Compiled Code) at org.apache.tomcat.core.ContextManager.service(Compiled Code) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Compiled Code) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Compiled Code) -- Nicolaus Bauman Software Engineer Simplexity Systems
[BUG TRACKING] Scarab schema and status etc.
Could someone with edit rights on Jakarta change the link to me as the Keeper of the Bugs from my yahoo email to this one? I'm talking about the link on: http://jakarta.apache.org/site/bugs.html Also, what's up with the Scarab schema: it's gone (the link is broken). Jon Stevens wants to be able to migrate the data from Bugrat directly into Scarab. I need his schema to do this. Can anyone help? Jon are you out there?
[BUG TRACKING] change to jakarta.apache.org
Sorry, I just noticed this. The link to BugRat in Jakarta needs a trailing slash. ie: http://znutar.cortexity.com/BugRatReport s/b http://znutar.cortexity.com/BugRatReport/ As I was unable to correct the mappings from apache into tomcat. For some reason no matter what I do, tomcat loses track of the request if it doesn't have a trailing slash. Thanks!
[BUG TRACKING] BugRat core
BugRat blew chunks last night. I had a core dump and a down znutar this morning with 32b7. This has never happened before.
Re: Bypassing IIS security
I remember when I worked for Imation we had that problem with IIS3-4 (you can't add web users without adding them to the system, ie 1 user to IIS is 1 user to that whole machine!) Anything to prevent this requirement would be greatly appreciated if I rewind my experience a couple years. On Sun, 19 Nov 2000, Nacho wrote: Hola A todos: Lately I'm trying to figure out a way to bypass the basic/digest security handling done by ISS, and so let it be done by tomcat, as it's a pain under IIS as it requires to have the users created at OS level, ( at least i unable to found a way to do that ), but apart from MS blues. I did found that way only by changing a single line inside the ajp12 handling routine , and letting remoteuser be obtained by tomcat itself, i think this works for all servers and for basicdigest authentication , Can be useful to know of to somebody, if anybody found it useful i can add an option to server.xml to control that ( at contextmanager level i.e) , and i'm thinking only of TC 3.3 and TC 4.0 at that time. What do you think? Saludos , Ignacio J. Ortega -- Nicolaus Bauman Software Engineer Simplexity Systems
Re: Closing Bug Reports?
Hans, I closed it for you. What the heck, what is BugRat doing now? It's been much better since Nacho and I fixed it (ie, hasn't been wedging mysql and sending my system spinning with a load average of, 80.69!) Now mind you, I've submitted out SQL fixes to BugRat back to Tim Endres and he doesn't seem interested. I kind get the feeling that he doesn't believe that the SQL was even a problem, like it's our imagination. *sigh* On Tue, 14 Nov 2000, Hans Bergsten wrote: I tried to find a way to close the following Bug Report through the admin interface, but no matter which option I choose I only get the admin menu: Bug report #380 has just been filed. [...] Synopsis: Sessions don't work without cookies If someone else has more BugRat karma than I do, please close this one since I have committed a solution to the tomcat_32 branch. Hans -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BUG REPORTING] Jakarta BugRat has been upgraded
Hello Jakarta Horde, BugRat has been upgraded to use Tomcat 3.2b7 + Apache 1.3.14 + mod_jserv. I will be adding cvsweb.cgi and anon cvs for the bugrat sources as I have been "patching" (or rather just hacking the hell out of) BugRat to whip it into shape. These are the things I've added that you won't find in the original sources: 1) report linking and closing audit trail 2) basic authentication for administrators 3) query optimization for searches (thanks to Mr. Ortega) Soon: 4) Fixes for the "workarounds" and "how to reproduce" fields so they display properly If anyone is considering BugRat for their internal BugTracking system, I would caution them that it's pretty well unusable without 3 and unpleasant without 1 2 *** Please let me know via this email if you notice any problems *** -Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 3.2 status -- no taglibs in jars
On Wed, 15 Nov 2000, Brian Bucknam wrote: On a separate topic, we're having some classloader problems where classes supposedly available in .jars in WEB-INF/lib come up as "NoClassDefFound" as supporting classes for some servlets and JSP pages. Moving these jars to jakarta-tomcat/lib solves the problem. I haven't had time to track down exactly where the problem is, but it seems wrong that the web-app classloader that loads the servlets JSP's seems to be ignoring the lib jars, or acting as if the classes in those jars came from a different loader. I probably should get better details before bringing this to the list, but I saw Rickard Öberg's mention of a getResource() problem... My $.02, Brian Regarding Tomcat 3.1 I've been talking to people at work who also use Tomcat and we've all come to the conclusion that the classloader for each context mapping is: A) Strange B) Slow C) To be avoided In other words, when in doubt, we end up sticking the classes and jars in Tomcat's classpath, (even the WEB-INF/classes directory!) and giving up on servlet reloading. Hopefully Tomcat 3.2 isn't as bad.
Re: Ant rant
On Mon, 13 Nov 2000 [EMAIL PROTECTED] wrote: If it works out-of-box with jikes 1.12, then awesome! (I've had problems with 1.12 because of the multibyte encoding changes between 1.11 and 1.12) I use it with jikes most of the time. If you are on unix, you can use an .antrc and ANT_OPTS="-Dbuild.compiler=jikes" BTW, if you are an expert ( or know how to use :-) autoconf, it would be really great to contribute an autoconf script for mod_jk ( and mod_warp when ready ). I'll look into it. I also think some of the features of autoconf ( like looking for a package in multiple places ) are very nice - for a while ( when I had more time ) I tried to port some of them to ant. That would be VERY cool. Another intersting project ( if you prefer makefiles ) is to write a simple XSL stylesheet to convert from Ant build.xml to a makefile. I think ( hope ) most of the ant tasks can be easily converted to the make equivalent ( java, cp, mkdir, etc ) and in the worse case a small "java runAntTask foo " can deal with the rest of the tasks. Yes, I mentioned something like this earlier. And when I say make I should clarify that I mean gmake, which is far more flexible than SysV make ( I like and use ant, but it's just a tool - and everyone should use whatever tools work best for him ) Costin As you could probably already figure, I'm becoming an Ant convert. The thing that broke the whole log jam for me was that I can continue to use jikes, which turns a project that takes 1 hour to compile with javac into 10 minutes with Jikes. -- Nicolaus Bauman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant rant
Question: WHAT THE HECK IS ANT? Now I know what ant is, I'm just hyperbolizing. But... It's just that I got the entire Tomcat 3.1 tree to compile with a single Makefile in around 10 minutes. I can't figure out what Ant is helping this project with. Maybe I'm just stupid or something but this Ant thing doesn't really impress me very much. Make is very stable, very cross platform; I just don't see what's so cool about ant. Why is ant better than Make? And don't say "ant is cross platform, make is not" because that just isn't true. Was someone just bored with the wheel and wanted to reinvent it? I just want to understand. Thanks. -Nick On Fri, 3 Nov 2000, Pier P. Fumagalli wrote: Question: WHAT THE HACK IS TOMCAT 3.3 ??? I believe that this developer community once agreed that Tomcat 4.0 _will_be_ the next major release of the Apache Software Foundation servlet engine, but, since a couple of weeks, I see a proliferation of emails talking about Tomcat 3.3. Here is where I'm getting confused... When did we vote about having a dual codebase for two different servlet engines at the same time??? Because I've never seen such a discussion taking place... Also, it seems ridiculous (at least to me) to start talking about what will be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the door, and as far as I've read (but I might have missed some emails) Beta-6 is not even compiling... Sorry, but as a long time ASF member, and one of the first kids involved in the glorious JServ, I feel that things here are getting a little bit screwed up. Are we going to screw our release cycles? Are we going out to the public with TWO servlet engines equal in features, but different in codebases? Are we all going NUTS? Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. But, I'm not _only_ a pain in the ass... I see there are some developers who prefer to work on the 3.x tree, rather than helping out on the 4.0, so, instead of cutting their wings and forcing them to fork the project, I propose to them what was proposed to Craig in february. The "Rules for Evolution and Revolutions" still stands still, as one of the major constitution documents for this community (James, WTF, post it somewhere!!! :) and IMNSHO needs to be used... I suggest to whoever is interested in further developement of the 3.3 tree to create a new proposal, as Craig did with Catalina, and stick it on the "proposals" directory in the CVS. And start working from it. I'm more than open to see, after Tomcat 4.0 sees light, to reconsider the effort, and maybe switching codebase again for what will be Tomcat 5.0. So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) 3) Release Tomcat 4.0 (with Catalina, as we all decided) 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. My 0.02 $... Take care... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant rant
"These kids today and their 'ant's! What's the world coming to?" But I'll agree, and _is_ more intuitive and elegant than Make. But I put them at about equal in difficulty in learning curve. BTW, for those who are interested, I've asked our CTO if I can release the maketools I used to compile Tomcat. Now, about my broken Tomcat 3.2b7 build... On Sun, 12 Nov 2000, person wrote: I'm another young developer, in the sense that I'm inexperienced - my first projects have been started about 8-9 months ago. I was faced with the choice of either learning ant or learning make, the two build systems available to me that I knew of. I expended a few hour of effort on each, and it's quite conclusive for me: ant is far and a way the more intuitive, elegant tool of the two. I grew up in OO concepts, it just feels like ant is a natural fit with java. Also, I seem to remember something on the ant page itself about why it was written instead of the author just using make. http://jakarta.apache.org/ant/, that's it. I give +1 for ant because of the learning curve involved, esp. when attracting new developers, considering that tomcat is likely to live a long lifetime and will likely (hopefully) see many new hands helping out. Micah Blake McCurdy The memory management on PowerPC can be used to frighten small children. -- Linus Torvalds On Sun, 12 Nov 2000, Rob S. wrote: Allow me to insert my Java / *nix developer novice-compared-to-people-here 2c =) I've only been paid to write Java code for 6 months as a co-op. There were 10+ developers at the company, and only one of them understood makefiles. That one person wrote and maintained a number of makefiles, and it really came down to not being "worth it" for the rest of us to understand the Makefile format. Why? When the files were there and working and everyone was happy. With Ant, I was able to accomplish the same thing, and fully understand the "whys" and "hows" of everything that was going on, in about 10 minutes (with the help of the ant docs and examples of course) and as many lines of XML. I've always considered it peripheral to getting "real work" done, so I don't wish to devote much brain power to it. Call me lazy, but that's just the way I am ;) I actually have dreaded having to learn the Makefile format for my personal projects and when I got a hold of Ant, I was very relieved! - r p.s. i don't mean to trivialize the Makefile stuff. It's funky! -Original Message- From: Nick Bauman [mailto:[EMAIL PROTECTED]] Sent: November 12, 2000 5:11 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Ant rant On Sun, 12 Nov 2000, Michael Stanley wrote: And don't say "ant is cross platform, make is not" because that just isn't true. Was someone just bored with the wheel and wanted to reinvent it? Ant is more than a cross platform make utility. Ant is platform independent, which means alot more than cross platform. Ant is a make utility geared to meeet the needs of Java. Java is "Write once run anywhere" and so is Ant. It is also specifically made to meet the build requirements of Java code, capable of anything from creating Jars to Javadocs. Its very easy to learn and its high modularity makes it very easy to expand. I guess this is an important distinction to some people. I'm not a purist; the JVM is written in C, so none of us can claim to be purists ;) Ant also goes further than make by adapting to XML for data representation and I assume there is no need for me to go into the benefits of that :) Once again, standard data representation as opposed to problem-specific data representation is an important distinction to some people. What would really be nice would be if there were some kind or translator that could convert a GNU Makefile into Ant build script and vice versa. Is this on the radar screen Ant devleopers? I have all kinds of problems using new versions of Tomcat (and someone said that they are suprised at how few people try the milestone builds / betas) and many of them come from problems with Ant. So I think Ant is actually _preventing_ people from getting the most out of Tomcat. (just an opinion: no flame intended!) Many many programs that use autoconf are out there in OSS. I feel like we aren't leveraging our own past. My 2 cents Michael Stanley And only mine as well, summarized by "Stand on The Shoulders of Giants" Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscrib
Re: 3.2b7 can't build -- fixed
I found what I was missing. It was a jar in my classpath.A On Sun, 12 Nov 2000, Nick Bauman wrote: What am I missing? I'm trying to build 3.2b7. [root@fatman jakarta-tomcat-3.2-b7-src]# ant Searching for build.xml ... Buildfile: /home/nick/build-web/jakarta-tomcat-3.2-b7-src/build.xml prepare: [chmod] /bin/chmod: too few arguments [chmod] Try `/bin/chmod --help' for more information. [chmod] Result: 1 tomcat: [javac] Compiling 1 source file to /home/nick/build-web/build/tomcat/classes[javac] /home/nick/build-web/jakarta-tomcat-3.2-b7-src/src/share/org/apache/tomcat/net/SSLSocketFactory.java:245: Class javax.security.cert.X509Certificate not found in type declaration. [javac] javax.security.cert.X509Certificate[] certChain = sslSocket.[javac]^ [javac] /home/nick/build-web/jakarta-tomcat-3.2-b7-src/src/share/org/apache/tomcat/net/SSLSocketFactory.java:245: Incompatible type for declaration. Can't convert javax.security.cert.X509Certificate[] to error[]. [javac] javax.security.cert.X509Certificate[] certChain = sslSocket.[javac] ^ [javac] 2 errors BUILD FAILED /home/nick/build-web/jakarta-tomcat-3.2-b7-src/build.xml:94: Compile failed, messages should have been provided. Total time: 18 seconds -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you describe your configuration? On Thu, 9 Nov 2000, [EMAIL PROTECTED] wrote: On Wed, 8 Nov 2000, Nick Bauman wrote: On Thu, 9 Nov 2000, Henri Gomez wrote: It is important that tomcat3 has a design that allows support for future versions of the servlet API, but if tomcat developers don't want to see it happen - so be it. When Servlet2.3 will be final and in wide use, there is nothing that can stop someone from providing the module that supports it ( not necesarily from apache site ). Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at least one or two years. Note that many importants sites still use Apache JServ (API 2.0) and GnuJSP. I for one, would love to see the 3.x codebase's Session API actually work "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. umm...it does. i use it. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
On Thu, 9 Nov 2000, Henri Gomez wrote: It is important that tomcat3 has a design that allows support for future versions of the servlet API, but if tomcat developers don't want to see it happen - so be it. When Servlet2.3 will be final and in wide use, there is nothing that can stop someone from providing the module that supports it ( not necesarily from apache site ). Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at least one or two years. Note that many importants sites still use Apache JServ (API 2.0) and GnuJSP. I for one, would love to see the 3.x codebase's Session API actually work "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bugrat 330
It's been linked to a bug. I do not know how much attention this is being given right now, however. On Sun, 5 Nov 2000, Matthew A. Overlund wrote: Just wondering if anyone has any as yet unposted solutions/suggestions to this bug report. It is in regard to long .class/.java file names on windows boxes generating an unable to write file error. Thanks Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC4-m4 CPU per request increase and thread queue locking?
Remy, Where is the source, it's not in the M4 sources, I just looked. Is it only in CVS? On Sun, 5 Nov 2000, Remy Maucherat wrote: - Original Message - From: "Nick Bauman" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 05, 2000 5:24 PM Subject: Re: TC4-m4 CPU per request increase and thread queue locking? On Sun, 5 Nov 2000, Craig R. McClanahan wrote: A very large chunk of Catalina's processing time is consumed by parsing the request headers, and converting them into a Request object that is passed on for processing. Volunteers who want one convenient place to start suggesting improvements can look at org.apache.connector.http.HttpProcessor -- there is an instance of this class running for each processor thread that is created. So does HttpProcessor use a pooler? If not, I would imagine this would be a huge performace benefit. Is anyone slated to do this? The request parsing has been cut paste from a very old version of Tomcat, and needs work, esp the HttpProcessor.read() function. I'll probably take care of the optimisation of the connector, but contributions in the "performance" area are more than welcome. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC4-m4 CPU per request increase and thread queue locking?
Excuse me for being dense, what is crimson.jar for in M4? On Sun, 5 Nov 2000, Craig R. McClanahan wrote: Nick Bauman wrote: On Sun, 5 Nov 2000, Craig R. McClanahan wrote: A very large chunk of Catalina's processing time is consumed by parsing the request headers, and converting them into a Request object that is passed on for processing. Volunteers who want one convenient place to start suggesting improvements can look at org.apache.connector.http.HttpProcessor -- there is an instance of this class running for each processor thread that is created. So does HttpProcessor use a pooler? If not, I would imagine this would be a huge performace benefit. Is anyone slated to do this? The instances of HttpProcessor -- each with an associated thread -- are indeed pooled and reused by the HttpConnector (the object that accepts incoming socket connections and hands them off for processing). Initially, the connector creates the number of instances that you specify in the minProcessors property (default=5), and the number grows up to the specified maximum if you get more simultaneous requests than you currently have processors. Once created, an HttpProcessor instance and its corresponding thread are never destroyed until the server is shut down. Idle threads sit on a wait() call (no "do you have work for me to do" type polling), so they don't consume any CPU time -- well, I'm assuming that threading was implemented competently in your JVM :-) -- and the memory footprint is pretty insigificant, so there did not seem to be any gain in harvesting them if the current level of server activity is low. Nicolaus Bauman Software Engineer Simplexity Systems Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
On Fri, 3 Nov 2000, Pier P. Fumagalli wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I'm not disagreeing with you Pier, but I will say I believe that there are 2 possible ways to interpret the current situation, and I do not think I'm the only one who thinks this. 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. 2) Or alternatively, anything beyond Tomcat 3.1 refects that Tomcat 3.1 is a "rolling beta", which means the "code-train" is in such bad shape that the developers are throwing track in front of it as it moves forward. Not a good thing. Or maybe we have a combination between the two. At any rate, ASF should rule clearly whether to let the code-train of 3.x roll off the track, whether to let it continue to roll on track but away from it's auspices, or to support the two code bases as is. By doing nothing ASF implicitly supports the latter, which is counterintuive to ASF's entire raison d'etre. my $0.02 -Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
The problem of the division of finite resources remains. Costin, would you consider bringing your brains into the 4.0 tree? Is 3.3 that good that it should weigh in _against_ (as a competeing implementation) 4.0? Pier, Craig, have you done all you can to get Costin "on-board" with 4.0? I just feel it a shame that Costin has this obvious empassioned pride of ownership in Tomcat and is sort of getting punished for it. I'm not saying it's malice, but it does seem somewhat insensitive. On Sat, 4 Nov 2000, Pier P. Fumagalli wrote: Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Arabic Encoding problem with tomcat!
I think this is a known bug. http://znutar.cortexity.com/BugRatViewer/ShowBug/48 I think if you report this, it will get linked to the same bug (#48). I do not know the status of this kind of behavior in TC 4.0. On Thu, 2 Nov 2000, Falcon cheetah wrote: I am using Tomcat 3.2.6 with Apache 1.3.14 on RH6.1. I am writing a WebMail application using JSP, JavaMail, etc. To write Arabic emails I wrote an applet that takes care of that and it works fine. My problem is when I send. my Editor_ar.jsp submits its form to handleMailaction.jsp where it should send the email. I have no problem sending emails using Editor.jsp, which is an all html English form. But when the handleMailaction.jsp gets the msgBody field that holds the Arabic message Tomcat starts acting on me. I keep getting messages about internal configuration error. How can I handle my input from that Applet! I am using ISO-8859-6, which is Arabic. Thanks for your help. Ahmed. __ Do You Yahoo!? From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[BUG TRACKING] searches re-enabled
Hello Jakarta-ers Thanks to some sharp thinking by Ignacio Ortega, I have converted the horrible sql BugRat originally used for searching with some better code. Suffice it to say, the original query would return in about 25 minutes. Ortega's code with the same data would returns in about 10 seconds. So what's that, an improvement of 150x? Hopefully with this kind of person on our side, Tomcat will eventually serve pages in the user's past. So happy searching! -- Nicolaus Bauman http://znutar.cortexity.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Character encoding problems [was BugRat Report #323 has been filed.]
3.2 and 3.3 devs: Why havn't Pilho's patches been incorporated into the main tree? -Nick On Wed, 1 Nov 2000, Pilho Kim wrote: Please check http://www.javaclue.org/tomcat/ Kim On Tue, 31 Oct 2000, BugRat Mail System wrote: Bug report #323 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/323 REPORT #323 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.1 JVM Release: jdk1.2.2 Operating System: Solaris OS Release: 2.6 Platform: Unix Synopsis: Tomcat 3.1 mishandles UTF-8 encoded text above the ascii range Description: My servlet produces UTF-8 encoded HTML pages that include encoded Unicode character values in the CJK range; I set the HttpServletResponse.ContentType in these cases to "text/html;charset=utf-8". Under an early issue of Tomcat 3.1, the UTF-8 encoded CJK characters got submitted to the browser properly; IE5 with the proper fonts installed was able to display theses characters just fine. Under the newest issue of Tomcat 3.1, however, the CJK characters in the HTML pages are replaced with "?"s before they are submitted to the browser! For another report of the same problem, see Stefan van den Oord's memo to the developers list on May 4, 2000: http://www.metronet.com/~wjm/tomcat/FromFeb11/msg01988.html ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/threads Reaper.java
Larry,
What bug or bug report is associated with this? Can you give me some clues
if you don't know?
On Mon, 30 Oct 2000, Larry Isaacs wrote:
Arion Yu should get credit for finding this first.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 26, 2000 10:45 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/util/threads Reaper.java
larryi 00/10/26 19:44:58
Modified:src/share/org/apache/tomcat/util/threads Reaper.java
Log:
Add synchronized so the notify() call won't throw an exception and prevent
Tomcat from shutting down.
Revision ChangesPath
1.3 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/threads/Reaper.java
Index: Reaper.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/threads/Reaper.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Reaper.java 2000/09/24 23:03:14 1.2
+++ Reaper.java 2000/10/27 02:44:58 1.3
@@ -120,7 +120,7 @@
this.start();
}
-public void stopReaper() {
+public synchronized void stopReaper() {
running=false;
this.notify();
}
-
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]
--
Nicolaus Bauman
Software Engineer
Simplexity Systems
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jBoss-Dev] Re: jboss on tomcat update
On Sat, 28 Oct 2000, marc fleury wrote: | What can I say? I agree that this is a reasonable interpretation. |But I don't think it's the only interpretation, and I'm not sure it's even |the interpretation intended by the authors. There's another section that |specifically allows distribution of GPL and non-GPL programs on the same |medium (Linux distributions), and that passage would be redundant if this |passage reads as you suggest. Listen it says if work is "containing, modifying, deriving" (CMD) of work that is GPL then GPL. If not, then not. (its' a mathematical if and only if) Ok let's loop on that for a while... Apache+Linux=aggregation, Apache is not CMD of Linux Frankly the wording is extremelly clear. GPL applies to "contained", "modified", or "derived" work not aggregated work and that is in the license what is not clear about it? I'll tell you, Marc, the word "contained" and the word "aggregated" as far as Java software goes, is what is extreemely unclear. The OO gurus do not even agree what the difference is between "contained" and "aggregated". Futhermore, I can change what I think is "contained" and what I think is "aggregated" in a Java program in a very technical fashion. So far I think Jon has a very salient point. -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jBoss-Dev] Re: jboss on tomcat update
On Sun, 29 Oct 2000, marc fleury wrote: THIS IS WHERE THE GPL DRAWS THE LINE FOR VIRALITY 4 Aggregation is the weakest, it just means bundling of work. GPL doesn't apply. Which to me means that the closest together the two can ever be is if Tomcat talks to JBoss and vice versa via a network socket. Then the two licenses can co-exist. Any code written to accept a Java interface after that network socket speaks would negate the legality, so you are stuck with something like http as your protocol. So why not just resort to sharp sticks and rocks while we're at it? But then as someone just mentioned, it matters not a stitch what you or I or Jon says, it matter what they lawyers say. -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOISE] [jBoss-Dev] Re: jboss on tomcat update
An aside, There is, AFAIK, one good reason to use GPL over any other Open Source or Free Software license, and it's a very very good reason: To maximize the spread of the GPL. IOW, it's to forward the tenets of freedom in software development and to more or less declare that other software is opposed to freedom. BSD-style licenses are trying to co-exist with closed software. GPL is trying to fight closed software. With GPL, it's a case of "the friend of my enemy is my enemy". I personally like the GPL for this reason, but then I am a tree-hugging pinko, like RMS. Not many of my colleages are and Eric Raymond for damn sure is not. (he would probably shoot me picketing a sawmill with one of his handguns) But if I want to co-exist with other non-tree-hugging-non-pinkos I'd better learn the art of compromise. :) -Nick On Sun, 29 Oct 2000, Jon Stevens wrote: Marc insists that GPL protects young code. I don't buy that either. LOL! That makes me laugh. So, when JBoss grows up, it can switch to a license for mature code (ie: BSD). :-) It sounds like JBoss is getting more mature. So, that argument suggests even further that there is no reason for JBoss to be GPL. If I GPL to protect my young code I assume my code is vulnerable to someone putting it into a commercial product and selling it where I would miss out on the revenue? Pshaw! There is no viable motive there. And every line of code I subseqently write undermines their commercial position. Bingo. Or another reason is because I'm afraid someone *gasp* will incorporate it into their other BSD-style licensed project and steal my mindshare / marketshare? So someone with more time and money and expertise might do a better job? Isn't that what we want? Better code? Or is _control_ over my crap-tastic code a better thing? I don't think so. LOL! -jon -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EmbedTomcat.java question (3.2b6) -- Must use Java 2
That's cool. I just wanted to mention it so that others who make assumptions like myself don't end up wasting their time like I did. At least the container works with 1.1. On Fri, 27 Oct 2000, Costin Manolache wrote: EmbededTomcat was introduced initially to allow J2EE integration, it may be possible to make it 1.1 compatible but it's not part of the "core" functionality. We never claimed we'll support all the features on 1.1, only that you'll have a working container. Costin --- Nick Bauman [EMAIL PROTECTED] wrote: Okay, this will NOT work with JDK 1.1. Deceptively, it will build with 1.1, but it just traipses around Java files that have Java2 specific calls. H. So I get a Tomcat 3.2b6 that might run, but won't embed. (FI, the EmbedTomcat.java doesn't get built) -Nick On Thu, 26 Oct 2000, Nick Bauman wrote: First: In the javadoc for the EmbedTomcat class, it says you need to set up the RequestInterceptors you want before firing up Tomcat. Well, if you read the code a little closer, it looks like a call to addContext(String contextPath, URL docroot) will automatically initialize the ContextManager and set up the default RequestInterceptors. Is this true? If so, then you only need to add your Interceptors explicitly if you have a custom Interceptor, no? Second: What is the contextPath String mean? Thanks -- Nicolaus Bauman Software Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems I'll give you $5 if you follow this link: https://secure.paypal.x.com/refer/pal=nixnixnix%40yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems I'll give you $5 if you follow this link: https://secure.paypal.x.com/refer/pal=nixnixnix%40yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EmbedTomcat.java question (3.2b6)
On Thu, 26 Oct 2000, Nick Bauman wrote: What is the contextPath String mean? Thanks The answer is the URL fragment the context is mapped to, for the ROOT context, the fragment is "/". Still not sure about the first one, but I'm going to go with my original assumption. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
