DO NOT REPLY [Bug 8940] - Tomcat shuts itself down for no apparent reason
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940 Tomcat shuts itself down for no apparent reason --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 17:38 --- JDK 1.4 That's the thing it actually does shut itself down in a totally orderly manner. catalina.out: [INFO] Registry - -Loading registry information [INFO] Registry - -Creating new Registry instance [INFO] Registry - -Creating MBeanServer [INFO] Http11Protocol - -setAttribute port 8080 [INFO] Http11Protocol - -setAttribute maxThreads 75 [INFO] Http11Protocol - -setAttribute backlog 10 [INFO] Http11Protocol - -setAttribute tcpNoDelay true [INFO] Http11Protocol - -setAttribute soTimeout 0 [INFO] Http11Protocol - -setAttribute timeout 0 [INFO] Http11Protocol - -setAttribute secure false Starting service Tomcat-Standalone Apache Tomcat/4.1 [INFO] Http11Protocol - -Starting on 8080 [INFO] JkMain - -Starting Jk2, base dir= c:\Programs\Tomcat40 conf=c:\Programs\Tomcat40\conf\jk2.properties [ERROR] JkMain - -APR error, disabling jni components: java.io.IOException: no apr in java.library.path [INFO] ChannelSocket - -JK: listening on tcp port 8009 [INFO] JkMain - -Jk running ID=0 ... init time=9003 ms Stopping service Tomcat-Standalone Same deal in localhost log: 2002-05-09 11:24:03 ContextConfig[/webdav]: Added certificates - request attribute Valve 2002-05-09 11:24:03 StandardManager[/webdav]: Seeding random number generator class java.security.SecureRandom 2002-05-09 11:24:03 StandardManager[/webdav]: Seeding of random number generator has been completed 2002-05-09 11:24:03 StandardWrapper[/webdav:default]: Loading container servlet default 2002-05-09 11:24:03 default: init 2002-05-09 11:24:03 StandardWrapper[/webdav:invoker]: Loading container servlet invoker 2002-05-09 11:24:03 invoker: init 2002-05-09 11:24:03 jsp: init 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path /manager 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path /mirs6 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path /examples 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path /tomcat-docs 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path /webdav 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path 2002-05-09 12:29:46 StandardHost[localhost]: Removing web application at context path /admin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 02/05/09 10:50:50
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Thanks Denis Benoit [EMAIL PROTECTED] for the patch.
. Removes the doAfterBody() from the finallies method and replace it with the
check of the value of the tagEvalVar variable;
. Removes superfluous call to addTagToVector() in the pseudo finally clause;
. addTagToVector() accepts an Object since a Tag can be passed or an Integer;
Revision ChangesPath
1.11 +9 -15
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Generator.java6 May 2002 04:33:15 - 1.10
+++ Generator.java9 May 2002 17:50:50 - 1.11
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
1.10 2002/05/06 04:33:15 glenn Exp $
- * $Revision: 1.10 $
- * $Date: 2002/05/06 04:33:15 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
1.11 2002/05/09 17:50:50 kinman Exp $
+ * $Revision: 1.11 $
+ * $Date: 2002/05/09 17:50:50 $
*
*
*
@@ -238,7 +238,7 @@
out.println();
out.println();
-out.printil(private void addTagToVector(java.util.Vector tags, int index,
javax.servlet.jsp.tagext.Tag tag) {);
+out.printil(private void addTagToVector(java.util.Vector tags, int index,
Object tag) {);
out.pushIndent();
out.printil(if (index + 1 tags.size()));
out.pushIndent();
@@ -1000,9 +1000,9 @@
out.println(););
out.printin(addTagToVector(tags, );
out.print(tryBitVal.toString());
-out.print(, );
-out.print(tagHandlerVar);
-out.println(););
+out.print(, new Integer();
+out.print(tagEvalVar);
+out.println()););
out.printin(if ();
out.print(tagEvalVar);
out.println( != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
{);
@@ -1070,12 +1070,6 @@
out.print(tryBitVal.toString());
out.println(););
-out.printin(addTagToVector(tags, );
-out.print(tryBitVal.toString());
-out.print(, );
-out.print(tagHandlerVar);
-out.println(););
-
out.printin(if ();
out.print(tagEvalVar);
out.println( != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE));
@@ -1085,9 +1079,9 @@
finallies.beginPartMethod(tryBitVal.intValue());
finallies.print( if ();
-
finallies.print(((javax.servlet.jsp.tagext.BodyTag)tags.elementAt();
+finallies.print(((Integer)tags.elementAt();
finallies.print(tryBitVal.toString());
-finallies.print()).doAfterBody());
+finallies.print()).intValue());
finallies.println( !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE));
finallies.println(out = pageContext.popBody(););
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8940] - Tomcat shuts itself down for no apparent reason
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940 Tomcat shuts itself down for no apparent reason --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:04 --- Are you running Tomcat as a service ? I don't have any explanation or idea about this bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8940] - Tomcat shuts itself down for no apparent reason
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940 Tomcat shuts itself down for no apparent reason --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:10 --- Nope, not as a service, just as standalone on 8080. It isn't killing me, as I'm only using it for development, but just thought I'd make note of it. Never seems to die when I'm using it. It's as if something is signaling it to die... but nothing is, unless some script has hung on somewhere out there... like the new reload ant task, but that doesn't make sense. Will try rebooting to see if that helps... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8940] - Tomcat shuts itself down for no apparent reason
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940 Tomcat shuts itself down for no apparent reason --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:21 --- Maybe it has to deal with the thread pool removing threads when TC is inactive. When the VM only has daemon threads running, it will shut itself down (and Tomcat, because of the shutdown hook). Costin, any comments on this ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8923] - writing to response.getOutputStream() over SSL doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923 writing to response.getOutputStream() over SSL doesn't work --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:46 --- I've done some more investigation... the problem only occurs when we run the server with a security constraint for the whole server. Here's the security constraint section from our web.xml: security-constraint web-resource-collection web-resource-name Troux Secure Area /web-resource-name url-pattern/*/url-pattern /web-resource-collection auth-constraint role-nametrouxuser/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint When we run the server with this constraint, any Struts action which sets an unusual content type fails... the user is prompted to open or save the file, but then Internet Explorer says it can't download the file. I'll attach an example struts action that demonstrates this. When we comment out the security constraint, everything runs fine. Also, when we run a simple servlet that does exactly the same thing (without using Struts), it runs as expected if there's no security constraint, but if there is a security constraint, Internet Explorer opens the response (even though the response headers should tell it to send the file down to the user.) I'll also attach a servlet demonstrating this. I've tried using Coyote connectors -- didn't help. Where can we get Tomcat 4.1.0? I only see links to Tomcat 4.0.x from the Tomcat website. Thanks for your help, Dan Rodney -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 02/05/09 11:47:15
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Fixed 4964: popBody called before doEndTag.
Revision ChangesPath
1.12 +20 -9
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Generator.java9 May 2002 17:50:50 - 1.11
+++ Generator.java9 May 2002 18:47:15 - 1.12
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
1.11 2002/05/09 17:50:50 kinman Exp $
- * $Revision: 1.11 $
- * $Date: 2002/05/09 17:50:50 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
1.12 2002/05/09 18:47:15 kinman Exp $
+ * $Revision: 1.12 $
+ * $Date: 2002/05/09 18:47:15 $
*
*
*
@@ -1070,6 +1070,10 @@
out.print(tryBitVal.toString());
out.println(););
+out.printin(int ret = );
+out.print(tagHandlerVar);
+out.println(.doEndTag(););
+
out.printin(if ();
out.print(tagEvalVar);
out.println( != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE));
@@ -1077,6 +1081,11 @@
out.printil(out = pageContext.popBody(););
out.popIndent();
+out.printil(if (ret ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE));
+out.pushIndent();
+out.printil(return;);
+out.popIndent();
+
finallies.beginPartMethod(tryBitVal.intValue());
finallies.print( if ();
finallies.print(((Integer)tags.elementAt();
@@ -1093,12 +1102,14 @@
out.printil(});
}
- out.printin(if ();
- out.print(tagHandlerVar);
- out.println(.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE));
- out.pushIndent();
- out.printil(return;);
- out.popIndent();
+if (n.getBody() == null || !implementsBodyTag) {
+ out.printin(if ();
+ out.print(tagHandlerVar);
+ out.println(.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE));
+ out.pushIndent();
+ out.printil(return;);
+ out.popIndent();
+}
// TryCatchFinally
if (implementsTryCatchFinally) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8923] - writing to response.getOutputStream() over SSL doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923 writing to response.getOutputStream() over SSL doesn't work --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:48 --- Created an attachment (id=1824) Example struts action -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8923] - writing to response.getOutputStream() over SSL doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923 writing to response.getOutputStream() over SSL doesn't work --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:49 --- Created an attachment (id=1825) Example servlet -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4964] - popBody() is called before doEndTag() is called in a BodyTag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4964. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4964 popBody() is called before doEndTag() is called in a BodyTag [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 18:52 --- Fixed in jasper2, which will be included in tc 4.1.x I also have a fix for the 4.0.x branch, but unfortunately ran into a problem with javac in sun.tools.javac (though OK with com.sun.tools.javac). The same javac works for jasper2, presumably because of the now flatten try/catch blocks. :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Prove me wrong - take this quiz
Hi, Developers and Developer-ettes! It is time for a fun quiz to test your knowledge of HTTP, Servlets, and servlet behavior. See if you can get them all right! As a bonus, see if you can guess how Tomcat handles these situations (as of 5/8/2002). Section 1 - HTTP - Question 1 HTTP 1.1 specification RFC 2616 defines 5 classes of status codes: 1xx, 2xx, 3xx, 4xx, and 5xx. What do the 2xx codes signify? A. Successful B. Redirection C. Client Error D. Server Error E. Successful only if the status code is 200 or 204, otherwise the server is free to change the Content-type and the message body. Question 2 What 2xx status codes are defined by RFC 2616? A. 200 - 206 B. several, but only look for 200 and 204. Question 3 If an HTTP application returns a 2xx code that is beyond the range of 2xx status codes, say 299, is it an error? A. No, it is by definition a success. B. Only 200 and 204 and really successful, other 2xx are errors. Section 2 - Servlet Container behavior -- A servlet wants to write to the client. It sets the status code to 299. It obtains a PrintWriter from the servlet container and writes to it. Question 1 Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. Question 3 The servlet spec allows you to write to the output by either obtaining a Writer or an OutputStream from the container, but not both. Should servlet container behave differently if application writes to OutputStream instead of Writer? A. No. Behavior should be consistent. B. If application returns 2xx other than 200 or 204, and it called getWriter(), then the response will be replaced, unless it has been committed via flush(), or if the application called getOutputStream(). Question 4 When is it ever acceptable to replace the content-type and message body when servlet is returning a 2xx status code? A. As a practical matter, it should never change the headers or body for any code less than 400. B. Only for status codes in the range 200-206 for which the RFC allows it (I didn't see any), and leave others alone. C. 200's and 204's work for me, everything else is fair game for silent replacement. Section 3 - Guess the output The following code samples are assumed to be in a servlet's service() method. Sample Code 1 - response.setStatus(299); response.setContentType(application/x-pig-latin); response.getWriter().println(an-Cay ou-yay ead-ray is-thay?); Question 1 What should the client see in the Content-type header? A. application/x-pig-latin B. text/html C. text/html, and by the way that's invalid D. text/html, that's invalid, and If you don't like it, you can disable it [or] write an alternate Question 2 What should the client see in the message body? A. The string an-Cay ou-yay ead-ray is-thay? B. Nicely stylized Tomcat error page. Sample Code 2 - response.setStatus(299); response.setContentType(application/x-pig-latin); Writer w = response.getWriter(); w.println(an-Cay ou-yay ead-ray is-thay?); w.flush(); Question 3 What should the client see in the message body? A. The string an-Cay ou-yay ead-ray is-thay? B. The string an-Cay ou-yay ead-ray is-thay?, but only because the response has been committed and the container's attempt to overwrite it failed. Sample Code 3 - response.setStatus(299); response.setContentType(application/x-pig-latin); response.getOutputStream().write(an-Cay ou-yay ead-ray is-thay?.getBytes()); Question 4 What should the client see in the message body? A. The string an-Cay ou-yay ead-ray is-thay? B. The string an-Cay ou-yay ead-ray is-thay?, but only because the application called getOutputSteam(), and the container's attempt to overwrite it failed when it called getWriter(). ANSWERS: Of course, these are loaded questions. :) A
DO NOT REPLY [Bug 8923] - writing to response.getOutputStream() over SSL doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923 writing to response.getOutputStream() over SSL doesn't work --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 19:27 --- I'm not sure if this is the same problem, but I found a similar bug here: http://www.apachelabs.org/tomcat-user/200203.mbox/%3c20020312152001.M87251- [EMAIL PROTECTED]%3e -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8923] - writing to response.getOutputStream() over SSL doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8923 writing to response.getOutputStream() over SSL doesn't work [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 19:39 --- I'm fairly certain this is the same as bug #6641. However, since that bug never really got fixed, I'm probably going to have to revert to Tomcat 4.0.1... I'd rather have a security hole than a broken web application! (And switching to only supporting Netscape is definitely NOT an option.) If you have any other suggestions on how I could deal with this, please let me know. *** This bug has been marked as a duplicate of 6641 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6641] - Download of MS Office docs from protected areas fail with IE
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6641 Download of MS Office docs from protected areas fail with IE [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 19:40 --- *** Bug 8923 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans MBeanUtils.java
amyroh 02/05/09 13:00:38
Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
Log:
Fix to encode url before creating mbean object name.
Revision ChangesPath
1.36 +8 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
Index: MBeanUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- MBeanUtils.java 3 May 2002 23:44:15 - 1.35
+++ MBeanUtils.java 9 May 2002 20:00:38 - 1.36
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.35 2002/05/03 23:44:15 amyroh Exp $
- * $Revision: 1.35 $
- * $Date: 2002/05/03 23:44:15 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
1.36 2002/05/09 20:00:38 amyroh Exp $
+ * $Revision: 1.36 $
+ * $Date: 2002/05/09 20:00:38 $
*
*
*
@@ -66,6 +66,7 @@
import java.io.InputStream;
import java.net.URL;
+import java.net.URLEncoder;
import javax.management.InstanceAlreadyExistsException;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanException;
@@ -114,7 +115,7 @@
*
* @author Craig R. McClanahan
* @author Amy Roh
- * @version $Revision: 1.35 $ $Date: 2002/05/03 23:44:15 $
+ * @version $Revision: 1.36 $ $Date: 2002/05/09 20:00:38 $
*/
public class MBeanUtils {
@@ -900,9 +901,10 @@
throws MalformedObjectNameException {
ObjectName name = null;
+String encodedResourceName = URLEncoder.encode(resource.getName());
name = new ObjectName(domain + :type=Resource,class= +
- resource.getType()+,name= +
- resource.getName());
+ resource.getType()+,name= +
+ encodedResourceName);
return (name);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/resources dataSources.jspf
manveen 02/05/09 13:17:54 Modified:webapps/admin banner.jsp webapps/admin/resources dataSources.jspf Log: * Fix for displaying the (decoded) URL name in the list of Data Source names. - While creating a new data source resource, the URL is used as the name in the object name to uniquely identify the mBean. -It had to be encoded to void MalformedObjectName exception since it contains special charactes : which the ObjectName c'tor doesn't like. * Minor fix for the banner. Removed width attribute from the banner image to prevent it from stretching and distorting. Revision ChangesPath 1.7 +1 -1 jakarta-tomcat-4.0/webapps/admin/banner.jsp Index: banner.jsp === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/banner.jsp,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- banner.jsp3 May 2002 22:59:30 - 1.6 +++ banner.jsp9 May 2002 20:17:54 - 1.7 @@ -18,7 +18,7 @@ table width=100% border=0 cellspacing=0 cellpadding=0 tr td align=left valign=middle -div class=masthead-title-text align=leftimg src=images/TomcatBanner.jpg width=430 height=120/div +div class=masthead-title-text align=leftimg src=images/TomcatBanner.jpg height=120/div /td form method='post' action='/admin/commitChanges.do' target='_self' td align=right valign=middle 1.6 +1 -1 jakarta-tomcat-4.0/webapps/admin/resources/dataSources.jspf Index: dataSources.jspf === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/resources/dataSources.jspf,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- dataSources.jspf 8 May 2002 02:50:05 - 1.5 +++ dataSources.jspf 9 May 2002 20:17:54 - 1.6 @@ -30,7 +30,7 @@ tddiv align=left class=table-normal-text html:link page='%= /resources/setUpDataSource.do?objectName= + URLEncoder.encode(dataSource) %' -controls:attribute name=dataSource attribute=name/ +controls:attribute name=dataSource attribute=url/ /html:link /div/td tddiv align=left class=table-normal-textnbsp; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_bean.h
costin 02/05/09 13:51:29 Modified:jk/native2/include jk_bean.h Log: Add a state, to prevent double initialization and simplify things. Add 'introspection' info about multi-value properties. I'm still looking into that ( the issue is how we save/restore/change dynamically multi-valued properties ) Added a 'version' field for each object - it will allow 'targeted' updates. I'm trying to generalize the mechanism used to update workes, so any attribute of any object can be set at runtime ( like in JMX world ), and to persist this automatically. Revision ChangesPath 1.2 +18 -0 jakarta-tomcat-connectors/jk/native2/include/jk_bean.h Index: jk_bean.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_bean.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jk_bean.h 8 May 2002 23:47:27 - 1.1 +++ jk_bean.h 9 May 2002 20:51:29 - 1.2 @@ -77,6 +77,10 @@ struct jk_bean; typedef struct jk_bean jk_bean_t; +#define JK_STATE_DISABLED 0 +#define JK_STATE_NEW 1 +#define JK_STATE_INIT 2 + /** * Factory used to create all jk objects. Factories are registered with * jk2_env_registerFactory. The 'core' components are registered in @@ -136,10 +140,17 @@ */ int debug; +int state; + /* Common information - if set the component will not be * initialized or used */ int disabled; + +/** Object 'version'. Used to detect changes in config. + * XXX will be set to the timestamp of the last config modification. + */ +long ver; /** Unprocessed settings that are set on this bean by the config apis ( i.e. with $() in it ). @@ -162,6 +173,13 @@ struct jk_pool *pool; /* Temp - will change !*/ + +/* Multi-value attributes. Must be declared so config knows how + to save them. XXX we'll have to use a special syntax for that, + the Preferences API and registry don't seem to support them. +*/ +char **multiValueInfo; + /* Attributes supported by getAttribute method */ char **getAttributeInfo; -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_config.h jk_uriEnv.h jk_uriMap.h
costin 02/05/09 13:52:54
Modified:jk/native2/include jk_config.h jk_uriEnv.h jk_uriMap.h
Log:
- removed old 'pull' apis from config, now everything works using the 'push' model
( i.e. setters ).
- removed unused stuff from config.
- removed duplicated 'debug' from uriEnv, uriMap
Revision ChangesPath
1.5 +1 -53 jakarta-tomcat-connectors/jk/native2/include/jk_config.h
Index: jk_config.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_config.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jk_config.h 8 May 2002 23:47:27 - 1.4
+++ jk_config.h 9 May 2002 20:52:54 - 1.5
@@ -90,7 +90,7 @@
/* Set an attribute for a jk object. This should be the
* only method called to configure objects. The implementation
- * should update the underlying repository in addition to setting
+ * will update the underlying repository in addition to setting
* the runtime value. Calling setAttribute on the object directly
* will only set the runtime value.
*/
@@ -104,51 +104,6 @@
char *targetFile);
-/** Read the properties from the file, doing $(prop) substitution
- * The source can be a file ( or uri ).
- */
-/* int (*read)(struct jk_env *env, jk_config_t *m, const char *source); */
-
-/** Write the properties, preserving the original format. Is it possible ?
- */
-/* int (*write)(struct jk_env *env, jk_config_t *m, const char *dest); */
-
-
-/* == Utilities and 'pull' access == */
-
-/** For multi-value properties, return the concatenation
- * of all values.
- *
- * @param sep Separators used to separate multi-values and
- * when concatenating the values, NULL for none. The first
- * char will be used on the result, the other will be
- * used to split. ( i.e. the map may either have multiple
- * values or values separated by one of the sep's chars )
- *
- */
-/* char *(*getValuesString)(struct jk_env *env, struct jk_map *m, */
-/* struct jk_pool *resultPool, */
-/* char *name, char *sep ); */
-
-
-/** For multi-value properties, return the array containing
- * all values.
- *
- * @param sep Optional separator, it'll be used to split existing values.
- *Curently only single-char separators are supported.
- */
-/* char **(*getValues)(struct jk_env *env, struct jk_map *m, */
-/* struct jk_pool *resultPool, */
-/* char *name, char *sep, int *count); */
-
-/**
- * Replace $(property) and ${property} in value.
- */
-/* char *(*replaceProperties)(struct jk_env *env, jk_config_t *m, */
-/*char *value, struct jk_pool *resultPool ); */
-
-
-
/* Private data */
struct jk_pool *pool;
void *_private;
@@ -159,13 +114,6 @@
char *section;
};
-
-/** Util: Split a string in components. */
-char **jk2_config_split(struct jk_env *env, struct jk_pool *pool,
-const char *listStr, const char *sep,
-unsigned *list_len );
-
-int jk2_config_str2int(struct jk_env *env, char *val );
char *jk2_config_replaceProperties(struct jk_env *env, struct jk_map *m,
struct jk_pool *resultPool,
1.13 +0 -4 jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h
Index: jk_uriEnv.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriEnv.h,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- jk_uriEnv.h 8 May 2002 23:47:27 - 1.12
+++ jk_uriEnv.h 9 May 2002 20:52:54 - 1.13
@@ -153,10 +153,6 @@
char *workerName;
struct jk_worker *worker;
-/** Debug for that location. Set with 'debug'
- */
-int debug;
-
/** For MATCH_TYPE_HOST, the list of aliases for the virtual host.
* Set using (multi-value ) 'alias' attribute on vhost uris.
*/
1.13 +0 -1 jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h
Index: jk_uriMap.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_uriMap.h,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- jk_uriMap.h 30 Apr 2002 06:42:35 - 1.12
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_worker.h
costin 02/05/09 13:58:13 Modified:jk/native2/include jk_worker.h Log: Switch the lb_factor/lb_value to int. For now we'll just use a small int ( 0..255 ) to represent the lb_value, and roll back to 0. The only role of lb_value is to make sure all workers get a similar amount of requests - with lb_factor giving more priority to some workers. There is little benefit on using floats for that, and a small int avoids the need for atomic operations. Note that we can still enhance the model to use the number of 'active connections' and favor the tomcat instances that have fewer active connections. We can also use the average response time ( after we add this info :-) Add multiple 'levels' - a genaralization of the 'local worker concept. At init time the channels are sorted by level in different tables ( currently we have 4 levels only, hardcoded - but I doubt we need more than 2 ). If all workers in a lower level are in error state, we move to the next. That removes the sepcial meaning of '0', Revision ChangesPath 1.19 +18 -16jakarta-tomcat-connectors/jk/native2/include/jk_worker.h Index: jk_worker.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_worker.h,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- jk_worker.h 8 May 2002 23:47:27 - 1.18 +++ jk_worker.h 9 May 2002 20:58:13 - 1.19 @@ -58,7 +58,7 @@ /*** * Description: Workers controller header file * * Author: Gal Shachor [EMAIL PROTECTED] * - * Version: $Revision: 1.18 $ * + * Version: $Revision: 1.19 $ * ***/ #ifndef JK_WORKER_H @@ -87,6 +87,13 @@ struct jk_map; typedef struct jk_worker jk_worker_t; +/* Number of lb levels/priorities. Workers are grouped by the level, + lower levels will allways be prefered. If all workers in a level are + in error state, we move to the next leve. +*/ +#define JK_LB_LEVELS 4 +#define JK_LB_MAX_WORKERS 256 + /* * The worker 'class', which represents something to which the web server * can delegate requests. @@ -181,8 +188,8 @@ * The information can be accessed by other components - * for example to report status, etc. */ -double lb_factor; -double lb_value; +int lb_factor; +int lb_value; /* Time when the last error occured on this worker */ time_t error_time; @@ -191,19 +198,14 @@ * ( number of requests or time ), if no other worker is active * or when the configuration changes. */ -int in_error_state; +int in_error_state; /* Worker priority. * Workers with lower priority are allways preffered - regardless of lb_value * This is user to represent 'local' workers ( we can call it 'proximity' or 'distance' ) */ -int priority; +int level; -/* I have no idea what it means... */ -int in_recovering; -/* I have no idea why we need this */ -int retry_count; - /* Information for reconfiguration */ /* Only one thread can update the config @@ -215,15 +217,15 @@ /* Information specific to the lb worker */ -/** For load balancing workers +/** Load balanced workers. Maps name-worker, used at config time. + * When the worker is initialized or refreshed it'll set the runtime + * tables. */ struct jk_map *lbWorkerMap; - -/* Cache for fast access. Do we need it ? XXX Move to a private structure */ -jk_worker_t **lb_workers; -int lb_workers_size; -int num_of_workers; +int workerCnt[JK_LB_LEVELS]; +jk_worker_t *workerTables[JK_LB_LEVELS][JK_LB_MAX_WORKERS]; + /* Methods supported by all workers */ /* * Do whatever initialization needs to be done to start this worker up. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_config.c
costin 02/05/09 14:00:53
Modified:jk/native2/common jk_config.c
Log:
Remove the old code.
Be less verbose ( unless config.debug property is set ).
Add another 'magic' attribute, info. It'll allow some comments to be
associated with each object, and persisted automatically.
( now the config will save the workers.properties whenever it receives
a request to do so - curently via shm, but we can easyly add the other
channels - what used to be called 1.4 is pretty close )
Revision ChangesPath
1.15 +20 -279 jakarta-tomcat-connectors/jk/native2/common/jk_config.c
Index: jk_config.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_config.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- jk_config.c 8 May 2002 23:50:37 - 1.14
+++ jk_config.c 9 May 2002 21:00:53 - 1.15
@@ -58,7 +58,7 @@
/***
* Description: General purpose config object *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.14 $ *
+ * Version: $Revision: 1.15 $ *
***/
#include jk_global.h
@@ -71,12 +71,6 @@
static void jk2_trim_prp_comment(char *prp);
static int jk2_trim(char *s);
-static char **jk2_config_getValues(jk_env_t *env, jk_config_t *m,
- struct jk_pool *resultPool,
- char *name,
- char *sep,
- int *countP);
-
/* */
@@ -203,8 +197,6 @@
No replacement or saving is done on the val - this is
a private method
*/
-
-
static int jk2_config_processBeanPropertyString( jk_env_t *env,
jk_config_t *cfg,
char *propertyString,
@@ -289,11 +281,21 @@
if( strcmp( name, name ) == 0 ) {
return JK_OK;
}
+if( strcmp( name, ver ) == 0 ) {
+mbean-ver=atol(val);
+return JK_OK;
+}
if( strcmp( name, debug ) == 0 ) {
mbean-debug=atoi( val );
+return JK_OK;
}
if( strcmp( name, disabled ) == 0 ) {
mbean-disabled=atoi( val );
+return JK_OK;
+}
+if( strcmp( name, info ) == 0 ) {
+/* do nothing, this is a comment */
+return JK_OK;
}
if( (mbean == cfg-mbean)
@@ -301,8 +303,9 @@
cfg-file != NULL ) {
/* 'file' property on ourself, avoid rec.
*/
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- config.setAttribute() ignore %s %s %s\n, mbean-name, name,
val );
+if( cfg-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ config.setAttribute() ignore %s %s %s\n, mbean-name,
name, val );
return JK_OK;
}
@@ -313,9 +316,10 @@
env-l-jkLog(env, env-l, JK_LOG_INFO,
config.setAttribute() Error setting %s %s %s\n,
mbean-name, name, val );
}
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- config.setAttribute() %d setting %s %s %s\n,
- cfg-mbean-debug, mbean-name, name, val );
+if( cfg-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ config.setAttribute() %d setting %s %s %s\n,
+ cfg-mbean-debug, mbean-name, name, val );
return rc;
}
return JK_ERR;
@@ -366,166 +370,6 @@
}
-char *jk2_config_getString(jk_env_t *env, jk_config_t *conf,
- const char *name, char *def)
-{
-char *val= conf-map-get( env, conf-map, name );
-if( val==NULL )
-return def;
-return val;
-}
-
-int jk2_config_getBool(jk_env_t *env, jk_config_t *conf,
- const char *prop, const char *def)
-{
-char *val=jk2_config_getString( env, conf, prop, (char *)def );
-
-if( val==NULL )
-return JK_ERR;
-
-if( strcmp( val, 1 ) == 0 ||
-strcasecmp( val, TRUE ) == 0 ||
-strcasecmp( val, ON ) == 0 ) {
-return JK_OK;
-}
-return JK_ERR;
-}
-
-/** Get a string property, using the worker's style
-for properties.
-Example worker.ajp13.host=localhost.
-*/
-static char *jk2_config_getStrProp(jk_env_t *env,
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c
costin 02/05/09 14:06:48
Modified:jk/native2/common jk_worker_lb.c
Log:
That's the big one.
Please review !
It changes the handling of lb_value to int. I also cleaned up the logic so
it's easier ( I hope ) to understand what's happening. Levels replace
the 'local worker', I thing I got the logic straight for those.
I started to add a 'introspection' data, to validate and better report
the config.
We use one table per level. At the moment the maximum number of workers
is hardcoded ( to 255 ), we could make it dynamic but that would make things
pretty complex when we add workers dynamically ( it won't work without
a CS or atomic operations )
Revision ChangesPath
1.12 +195 -181 jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
Index: jk_worker_lb.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_worker_lb.c9 May 2002 00:01:43 - 1.11
+++ jk_worker_lb.c9 May 2002 21:06:48 - 1.12
@@ -77,6 +77,7 @@
/* XXX make it longer - debugging only */
#define WAIT_BEFORE_RECOVER (5)
+#define MAX_ATTEMPTS 3
/** Find the best worker. In process, check if timeout expired
for workers that failed in the past and give them another chance.
@@ -90,115 +91,157 @@
jk_ws_service_t *s, int attempt)
{
jk_worker_t *rc = NULL;
-double lb_min = 0.0;
+int lb_min = 0;
+int lb_max = 0;
int i;
+int j;
+int level;
+int currentLevel=JK_LB_LEVELS - 1;
char *session_route;
time_t now = 0;
session_route = jk2_requtil_getSessionRoute(env, s);
if(session_route) {
-for(i = 0 ; i lb-num_of_workers ; i++) {
-jk_worker_t *w=lb-lb_workers[i];
-
-if(w-route != NULL
- 0 == strcmp(session_route, w-route)) {
-if(attempt 0 w-in_error_state) {
- break;
-} else {
-return w;
- }
+for( level=0; levelJK_LB_LEVELS; level++ ) {
+for(i = 0 ; i lb-workerCnt[level]; i++) {
+jk_worker_t *w=lb-workerTables[level][i];
+
+if(w-route != NULL
+ 0 == strcmp(session_route, w-route)) {
+if(attempt 0 w-in_error_state) {
+/* We already tried to revive this worker. */
+break;
+} else {
+return w;
+}
+}
}
}
}
-/** Get one worker that is ready */
-for(i = 0 ; i lb-num_of_workers ; i++) {
-jk_worker_t *w=lb-lb_workers[i];
-
-if(w-in_error_state) {
+/** Get one worker that is ready
+ */
+for( level=0; levelJK_LB_LEVELS; level++ ) {
+for(i = 0 ; i lb-workerCnt[level] ; i++) {
+jk_worker_t *w=lb-workerTables[level][i];
+
if( w-mbean-disabled ) continue;
-
-/* Check if it's ready for recovery */
-/* if(!lb-lb_workers[i]-in_recovering) { */
-if( now==0 )
-now = time(NULL);
-
-if((now - w-error_time) WAIT_BEFORE_RECOVER) {
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
- lb.getWorker() timeout expired, reenable again %s\n,
- w-mbean-name);
-
-w-in_recovering = JK_TRUE;
-w-in_error_state = JK_FALSE;
+if( w-in_error_state ) continue;
-/* No need to do that - if it'll be used again, then error time
- will be set automatically on error */
-/* w-error_time = now; */
-/* Not sure we need that either */
-/* w-retry_count++; */
-
-/* The worker's error state is reset, but that doesn't
- mean it'll be used - normal priority selection happens
- Don't give bigger priority to recovered workers
-*/
-/* rc = lb-lb_workers[i];
- break;
-*/
+if( rc==NULL ) {
+rc=w;
+currentLevel=level;
+lb_min=w-lb_value;
+continue;
}
-}
-if( ! lb-lb_workers[i]-in_error_state ) {
-if(lb-lb_workers[i]-lb_value == 0 ) {
-/* That's the 'default' worker,
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c
costin 02/05/09 14:09:41
Modified:jk/native2/common jk_worker_status.c
Log:
Much cleaner and easier to read report, remove duplicated code and
generalize a bit.
We'll display a table for each object type ( that we care about ):
- ajp workers
- uris
- endpoints
For each object we display all we can get via 'getters' ( if you want more
info, just add a new attribute for getAttribute ).
The workers are the important piece - the state and counters.
Note that at this moment we display only the info in the apache instance
that is active. It'll change to use the shmem scoreboard.
Revision ChangesPath
1.18 +37 -114 jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
Index: jk_worker_status.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- jk_worker_status.c3 May 2002 18:10:58 - 1.17
+++ jk_worker_status.c9 May 2002 21:09:41 - 1.18
@@ -74,38 +74,16 @@
#include jk_requtil.h
#include jk_registry.h
-static void jk2_worker_status_displayActiveProperties(jk_env_t *env,
jk_ws_service_t *s,
- jk_workerEnv_t *wenv)
-{
-jk_map_t *map=wenv-initData;
-int i;
-
-s-jkprintf(env, s, H3Processed config/H3\n);
-s-jkprintf(env, s, pAll settings ( automatic and configured ), after
substitution/p\n);
-
-s-jkprintf(env, s, table border\n);
-s-jkprintf(env, s, trthName/ththValue/td/tr\n);
-for( i=0; i map-size( env, map ) ; i++ ) {
-char *name=map-nameAt( env, map, i );
-char *value=(char *)map-valueAt( env, map,i );
-s-jkprintf(env, s, trtd%s/tdtd%s/td/tr, name,
-value);
-}
-s-jkprintf(env, s, /table\n);
-
-}
-
-static void jk2_worker_status_displayRuntimeWorkers(jk_env_t *env, jk_ws_service_t
*s,
- jk_workerEnv_t *wenv)
+/** Use 'introspection' data to find what getters an type support,
+ * and display the information in a table
+ */
+static void jk2_worker_status_displayRuntimeType(jk_env_t *env, jk_ws_service_t *s,
+ jk_workerEnv_t *wenv, char *type)
{
jk_map_t *map=wenv-initData;
int i;
int needHeader=JK_TRUE;
-s-jkprintf(env, s, H3Worker runtime info/H3\n);
-s-jkprintf(env, s, pWorker information, using getAttribute() /p\n);
-
-s-jkprintf(env, s, table border\n);
for( i=0; i env-_objects-size( env, env-_objects ); i++ ) {
char *name=env-_objects-nameAt( env, env-_objects, i );
jk_bean_t *mbean=env-_objects-valueAt( env, env-_objects, i );
@@ -122,10 +100,14 @@
if( mbean-getAttribute == NULL )
continue;
-if( strncmp( ajp13, mbean-type, 5 ) != 0 )
+if( strncmp( type, mbean-type, 5 ) != 0 )
continue;
if( needHeader ) {
+s-jkprintf(env, s, H3%s runtime info/H3\n, type);
+s-jkprintf(env, s, p%s information, using getAttribute() /p\n,
type);
+
+s-jkprintf(env, s, table border\n);
s-jkprintf(env, s, trthname/th\n);
for( j=0; mbean-getAttributeInfo[j] != NULL; j++ ) {
char *pname=mbean-getAttributeInfo[j];
@@ -143,95 +125,35 @@
mbean-getAttribute( env, mbean, pname));
}
}
-s-jkprintf( env,s , /table\n );
-}
-
-static void jk2_worker_status_displayRuntimeUris(jk_env_t *env, jk_ws_service_t *s,
- jk_workerEnv_t *wenv)
-{
-jk_map_t *map=wenv-initData;
-int i;
-
-s-jkprintf(env, s, H3URI info/H3\n);
-s-jkprintf(env, s, pInformation about uri mappings.
-Will include some statistics ( for the active process )/p\n);
-s-jkprintf(env, s, table border\n);
-s-jkprintf(env, s, trthName/ththValue/td/tr\n);
-for( i=0; i env-_objects-size( env, env-_objects ); i++ ) {
-char *name=env-_objects-nameAt( env, env-_objects, i );
-jk_bean_t *mbean=env-_objects-valueAt( env, env-_objects, i );
-int j;
-int propCount;
-
-/* Don't display aliases */
-if( strchr(name, ':')==NULL )
-continue;
-
-if( mbean==NULL || mbean-getAttributeInfo==NULL )
-continue;
-
-if( mbean-getAttribute == NULL )
-continue;
-
-if( strncmp( uri, mbean-type, 3 ) != 0 )
-continue;
-
-for( j=0; mbean-getAttributeInfo[j] != NULL; j++ ) {
-char
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c mod_jk2.c
costin 02/05/09 14:13:13
Modified:jk/native2/jni jk_jni_aprImpl.c
jk/native2/server/apache2 jk_service_apache2.c mod_jk2.c
Log:
As previously mentioned, less verbosity unless explicitely configured for debug
( and only debug on the targeted object )
Revision ChangesPath
1.15 +1 -1 jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c
Index: jk_jni_aprImpl.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/jni/jk_jni_aprImpl.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- jk_jni_aprImpl.c 9 May 2002 00:08:50 - 1.14
+++ jk_jni_aprImpl.c 9 May 2002 21:13:12 - 1.15
@@ -356,7 +356,7 @@
jlong poolJ, jstring hostJ )
{
apr_pool_t *pool=(apr_pool_t *)(void *)(long)poolJ;
-char *host;
+const char *host;
int status;
int unixSocket;
struct sockaddr_un unixAddr;
1.19 +5 -5
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
Index: jk_service_apache2.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- jk_service_apache2.c 9 May 2002 00:10:57 - 1.18
+++ jk_service_apache2.c 9 May 2002 21:13:12 - 1.19
@@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat
* Author: Gal Shachor [EMAIL PROTECTED]
* Henri Gomez [EMAIL PROTECTED]
- * Version: $Revision: 1.18 $
+ * Version: $Revision: 1.19 $
*/
#include apu_compat.h
@@ -108,7 +108,7 @@
return JK_ERR;
if( s-uriEnv != NULL )
-debug=s-uriEnv-debug;
+debug=s-uriEnv-mbean-debug;
r = (request_rec *)s-ws_private;
@@ -146,8 +146,8 @@
/* XXX As soon as we switch to jk_map_apache2, this will not be needed ! */
if( debug 0 )
env-l-jkLog(env, env-l, JK_LOG_INFO,
- service.head() %d %d\n, s-status,
- numheaders);
+ service.head() %d %d %p\n, s-status,
+ numheaders, s-uriEnv);
for(h = 0 ; h numheaders; h++) {
char *name=headers-nameAt( env, headers, h );
@@ -258,7 +258,7 @@
return JK_ERR;
}
if( s-uriEnv != NULL )
-debug=s-uriEnv-debug;
+debug=s-uriEnv-mbean-debug;
if(len==0 ) {
return JK_OK;
1.18 +21 -17jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
Index: mod_jk2.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- mod_jk2.c 9 May 2002 00:10:57 - 1.17
+++ mod_jk2.c 9 May 2002 21:13:12 - 1.18
@@ -59,7 +59,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.17 $ *
+ * Version: $Revision: 1.18 $ *
***/
/*
@@ -302,7 +302,7 @@
workerEnv-initData-add( env, workerEnv-initData, serverRoot,
workerEnv-pool-pstrdup( env, workerEnv-pool,
ap_server_root));
-env-l-jkLog(env, env-l, JK_LOG_ERROR, Set serverRoot %s\n, ap_server_root);
+env-l-jkLog(env, env-l, JK_LOG_INFO, Set serverRoot %s\n, ap_server_root);
/* Local initialization */
workerEnv-_private = s;
@@ -432,13 +432,13 @@
if( rc == JK_OK gPool != NULL ) {
/* This is the first step */
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
+env-l-jkLog(env, env-l, JK_LOG_INFO,
mod_jk.post_config() first invocation\n);
apr_pool_userdata_set( INITOK, mod_jk_init, NULL, gPool );
return OK;
}
-env-l-jkLog(env, env-l, JK_LOG_ERROR,
+env-l-jkLog(env, env-l, JK_LOG_INFO,
mod_jk.post_config() second invocation\n );
@@ -524,12 +524,9 @@
r-uri, worker-mbean-name);
} else {
Re: Prove me wrong - take this quiz
Question 1 Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) If you instantiate a buffered writer yourself (instead of using resp.getWriter) to wrap around resp.getOutputStream, you have to flush it. So it's B. Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. If the servlet didn't do anything other that set headers, and did not write any content, it doesn't contrdict any spec, and is desirable if the client is a web browser. B also. Question 3 The servlet spec allows you to write to the output by either obtaining a Writer or an OutputStream from the container, but not both. Should servlet container behave differently if application writes to OutputStream instead of Writer? A. No. Behavior should be consistent. B. If application returns 2xx other than 200 or 204, and it called getWriter(), then the response will be replaced, unless it has been committed via flush(), or if the application called getOutputStream(). A, and behavior IS consistent. All your examples from section 3 would work fine. They don't do the same thing as the invalid test case you attached to the report, in that they actually do write the bytes. I have been frustrated in multiple attempts to report this very glaring bug, because the reviewer chooses to close the bugs, dismissing them out-of-hand as invalid without addressing a single fact, without being able to muster a technical argument to where I might be mistaken. Your bug really is invalid, but you don't seem to be reading the comments. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/resources dataSource.jsp dataSources.jspf
manveen 02/05/09 14:27:27
Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin
ApplicationResources_en.properties
ApplicationResources_es.properties
webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources
DataSourceForm.java SaveDataSourceAction.java
SetUpDataSourceAction.java
webapps/admin/resources dataSource.jsp dataSources.jspf
Log:
* Added JNDI name to Data Source, used this attribute for the resource Name while
creating a new mBean for this Resource..
* Display list now displays JNDI name, JDBC class.
* Added a validation check that JNDI name is required while creating a new resource.
* JNDI Name can is editable only on create, while now URL can be edited any time.
Revision ChangesPath
1.58 +1 -0
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties
Index: ApplicationResources_en.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_en.properties,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- ApplicationResources_en.properties9 May 2002 01:41:51 - 1.57
+++ ApplicationResources_en.properties9 May 2002 21:27:27 - 1.58
@@ -298,6 +298,7 @@
resources.userdb.factory=Factory
resources.treeBuilder.databases=User Databases
resources.error.path.required=liPath is required/li
+resources.error.jndiName.required=liJNDI Name is required/li
# -- User Database Module --
users.actions.group.create=Create New Group
1.49 +2 -1
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties
Index: ApplicationResources_es.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/ApplicationResources_es.properties,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- ApplicationResources_es.properties8 May 2002 00:41:18 - 1.48
+++ ApplicationResources_es.properties9 May 2002 21:27:27 - 1.49
@@ -297,7 +297,8 @@
resources.userdb.location=Location
resources.userdb.factory=Factory
resources.treeBuilder.userdbs=User Databases
-resources.error.path.required=liPath is required/li
+resources.error.path.required=liPath requerido/li
+resources.error.jndiName.required=liJNDI Nombre requerido/li
# -- User Database Module --
users.actions.group.create=Cree Al Nuevo Grupo
1.3 +26 -7
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/DataSourceForm.java
Index: DataSourceForm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/DataSourceForm.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DataSourceForm.java 7 May 2002 23:37:55 - 1.2
+++ DataSourceForm.java 9 May 2002 21:27:27 - 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/DataSourceForm.java,v
1.2 2002/05/07 23:37:55 manveen Exp $
- * $Revision: 1.2 $
- * $Date: 2002/05/07 23:37:55 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/DataSourceForm.java,v
1.3 2002/05/09 21:27:27 manveen Exp $
+ * $Revision: 1.3 $
+ * $Date: 2002/05/09 21:27:27 $
*
*
*
@@ -75,7 +75,7 @@
* Form bean for the individual data source page.
*
* @author Manveen Kaur
- * @version $Revision: 1.2 $ $Date: 2002/05/07 23:37:55 $
+ * @version $Revision: 1.3 $ $Date: 2002/05/09 21:27:27 $
* @since 4.1
*/
@@ -101,6 +101,18 @@
this.url = url;
}
+/**
+ * The JNDI name of the data source.
+ */
+private String jndiName = null;
+
+public String getJndiName() {
+return (this.jndiName);
+}
+
+public void setJndiName(String jndiName) {
+this.jndiName = jndiName;
+}
/**
* The JDBC driver class of the data source.
@@ -220,12 +232,13 @@
public void reset(ActionMapping mapping, HttpServletRequest request) {
super.reset(mapping, request);
-url = null;
+url = null;
+jndiName = null;
driverClass = null;
username =
DO NOT REPLY [Bug 8940] - Tomcat shuts itself down for no apparent reason
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8940 Tomcat shuts itself down for no apparent reason --- Additional Comments From [EMAIL PROTECTED] 2002-05-09 21:29 --- That's fine. It was worth reporting it, because it may happen to others. Cygwin doesn't seem to be a very good platform to run production apps on, so I don't see the point of supporting it (esp since it adds many hacks in the Unix scripts). Better cross platform support and enhanced reliability (like VM restart in the event of a crash) will probably come from the daemon component from the commons. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources SaveDataSourceAction.java
manveen 02/05/09 14:32:43 Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources SaveDataSourceAction.java Log: * no need to set the name attribute on update operation. This is needed only for addResource during create. Revision ChangesPath 1.4 +4 -7 jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java Index: SaveDataSourceAction.java === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- SaveDataSourceAction.java 9 May 2002 21:27:27 - 1.3 +++ SaveDataSourceAction.java 9 May 2002 21:32:43 - 1.4 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java,v 1.3 2002/05/09 21:27:27 manveen Exp $ - * $Revision: 1.3 $ - * $Date: 2002/05/09 21:27:27 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/resources/SaveDataSourceAction.java,v 1.4 2002/05/09 21:32:43 manveen Exp $ + * $Revision: 1.4 $ + * $Date: 2002/05/09 21:32:43 $ * * * @@ -96,7 +96,7 @@ * updated data source entry./p * * @author Manveen Kaur - * @version $Revision: 1.3 $ $Date: 2002/05/09 21:27:27 $ + * @version $Revision: 1.4 $ $Date: 2002/05/09 21:32:43 $ * @since 4.1 */ @@ -209,9 +209,6 @@ ObjectName oname = new ObjectName(objectName); -attribute = name; -mserver.setAttribute -(oname, new Attribute(attribute,dataSourceForm.getJndiName())); attribute = url; mserver.setAttribute (oname, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
On Thu, 9 May 2002, Remy Maucherat wrote: Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) If you instantiate a buffered writer yourself (instead of using resp.getWriter) to wrap around resp.getOutputStream, you have to flush it. So it's B. That's a java limitation BTW, if you wrap the writer returned by getWriter there's no way to get the info from the wraper's buffer ( if you use a BufferedWriter or something ). But if you just use the original writer it should work without a flush. ( and I think it does work ) Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. If the servlet didn't do anything other that set headers, and did not write any content, it doesn't contrdict any spec, and is desirable if the client is a web browser. B also. I'm not sure I agree - if the user want to send an empty page ( with a 2xx response ) that's perfectly fine. For 4xx he is required to define error-pages in web.xml if he wants, and the server may use whatever defaults ( since the user can tune the behavior in web.xml ), but for 2xx it's a bad idea to mess with the content. Some headers ( like Content-Length, Content-Type ) can/should be altered ( to insert the charset or set a default content type ) ( I'm not sure we are allowed to set a default content type if a servlet didn't suplied one - again if the user doesn't want one he should be able to get that ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c
costin 02/05/09 14:49:01 Modified:jk/native2/common jk_workerEnv.c Log: Sometimes env is not set. Revision ChangesPath 1.38 +4 -5 jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c Index: jk_workerEnv.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- jk_workerEnv.c9 May 2002 21:03:07 - 1.37 +++ jk_workerEnv.c9 May 2002 21:49:01 - 1.38 @@ -59,7 +59,7 @@ * Description: Workers controller * * Author: Gal Shachor [EMAIL PROTECTED] * * Author: Henri Gomez [EMAIL PROTECTED] * - * Version: $Revision: 1.37 $ * + * Version: $Revision: 1.38 $ * ***/ #include jk_env.h @@ -369,10 +369,9 @@ return JK_ERR; } -if( e-worker-mbean-debug 0 ) -env-l-jkLog(env, env-l, JK_LOG_INFO, - workerEnv.dispatch() Calling %d %s\n, handler-messageId, - handler-name); +/* env-l-jkLog(env, env-l, JK_LOG_INFO, */ +/* workerEnv.dispatch() Calling %d %s\n, handler-messageId, */ +/* handler-name); */ /* Call the message handler */ rc=handler-callback( env, target, e, msg ); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/lib commons-logging.jar
costin 02/05/09 15:02:54 Modified:lib commons-logging.jar Log: Updated the logging package from cvs-head. It'll display the currect class name for jdk1.4, and will create a sane ( consistent with the defaults for simple and jdk1.4 ) config for log4j, if none is specified. Plus it has a Class-Path attribute, so less CLASSPATH required for cli. Revision ChangesPath 1.3 +60 -112 jakarta-tomcat-connectors/lib/commons-logging.jar Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/lib commons-logging.jar
costin 02/05/09 15:12:07 Modified:lib commons-logging.jar Log: It helps if I check in the current version :-) Revision ChangesPath 1.4 +25 -8 jakarta-tomcat-connectors/lib/commons-logging.jar Binary file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Remy Maucherat wrote: Question 1 Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) If you instantiate a buffered writer yourself (instead of using resp.getWriter) to wrap around resp.getOutputStream, you have to flush it. So it's B. Wrong again, Remy. And please stop introducing diversions like instantiating a buffered writer yourself. The bug exists with the Writer returned from the container. Please go the the Java Servlet Specification, v2.2 Final Release. Where does it put the burden of flushing buffer on the web application? Please cite the chapter and section. Of course you can't because it is not there. Why is Tomcat 4.0.x is the only servlet container that requires this strange behavior? Old JServ didn't. WebLogic doesn't. I don't see how a reasonable developer can not answer A. Also, what is this business you said about because of timing problems, the bytes will not get written? Do other developers agree with this statement? Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. If the servlet didn't do anything other that set headers, and did not write any content, it doesn't contrdict any spec, and is desirable if the client is a web browser. B also. Please don't introduce another diversion that it somehow matters whether the servlet set any body content or not. If it is 2xx, leave it alone. It is reasonable even to leave 3xx responses alone. And for the record, the bug exists if body content has been written. Your answer again does not make sense. Here is a real-world example. Say I write a WebDAV servlet. It writes text/xml. It returns 207, which is not an error. Nor is this an invalid test case. Now if the XML body is relatively short (smaller than whatever the container sets the buffer size in the Writer), when my servlet relinquishes control to Tomcat, Tomcat will stomp the body and change the content type! Please explain again to everyone why this is the right behavior. Right now the only way to work around this behavior is to write a longer message, which causes the container-provided Writer to internally flush its buffer, or to force all servlet authors to manually call flush(). And remember, this is just a workaround. ErrorReportValve.java is still trying to overwrite the response- it just can't do it once the response is committed. Your bug really is invalid, but you don't seem to be reading the comments. Then when will you cite an RFC or specification to contradict my argument? I give you overwhelming and specific evidence of a bug, yet you don't contradict even one of my statements. I am confident that you can't. Still I wait for an rebuttal with technical merit. I can justify every single assertion that I have made and back them up with RFC, specification, or common sense. -Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
On Fri, 2002-05-10 at 04:55, Steve McCarthy wrote: I have been frustrated in multiple attempts to report this very glaring bug Gee, I would have never guessed that one ;-) Bojan PS. Sorry, had to have some fun... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Steve,
In 8916 - if you use:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
If you use w=response.getWriter() than it should work without flush,
since the container does have access to the buffer ( in the first
case the container has no way to access your writer )
I agree that a 2xx response with empty content is perfectly valid
and shouldn't be modified, that's a bug.
Costin
On Thu, 9 May 2002, Steve McCarthy wrote:
Remy Maucherat wrote:
Question 1
Does servlet specification require you to call flush() to ensure that
the client actually see the bytes?
A. No, spec does not mandate this behavior for webapps.
B. you have to flush your writer. Otherwise, because of timing
problems, the bytes will not get written (bug 8916)
If you instantiate a buffered writer yourself (instead of using
resp.getWriter)
to wrap around resp.getOutputStream, you have to flush it.
So it's B.
Wrong again, Remy. And please stop introducing diversions like
instantiating a buffered writer yourself. The bug exists with the
Writer returned from the container.
Please go the the Java Servlet Specification, v2.2 Final Release.
Where does it put the burden of flushing buffer on the web application?
Please cite the chapter and section. Of course you can't because it is
not there.
Why is Tomcat 4.0.x is the only servlet container that requires this
strange behavior? Old JServ didn't. WebLogic doesn't.
I don't see how a reasonable developer can not answer A.
Also, what is this business you said about because of timing problems,
the bytes will not get written? Do other developers agree with this
statement?
Question 2
Where in servlet spec (or RFC 2616, your choice) does it allow
the container to replace the message body or content-type header for
an
application that has set the status code to 2xx?
A. It doesn't. It shouldn't. That would be clearly wrong.
B. 200's and 204's are left alone, all other 2xx status codes are
fair game to have their headers and body replaced.
If the servlet didn't do anything other that set headers, and did not write
any
content, it doesn't contrdict any spec, and is desirable if the client is a
web browser.
B also.
Please don't introduce another diversion that it somehow matters whether
the servlet set any body content or not. If it is 2xx, leave it alone.
It is reasonable even to leave 3xx responses alone. And for the
record, the bug exists if body content has been written.
Your answer again does not make sense. Here is a real-world example.
Say I write a WebDAV servlet. It writes text/xml. It returns 207,
which is not an error. Nor is this an invalid test case.
Now if the XML body is relatively short (smaller than whatever the
container sets the buffer size in the Writer), when my servlet
relinquishes control to Tomcat, Tomcat will stomp the body and change
the content type!
Please explain again to everyone why this is the right behavior.
Right now the only way to work around this behavior is to write a longer
message, which causes the container-provided Writer to internally flush
its buffer, or to force all servlet authors to manually call flush().
And remember, this is just a workaround. ErrorReportValve.java is still
trying to overwrite the response- it just can't do it once the response
is committed.
Your bug really is invalid, but you don't seem to be reading the comments.
Then when will you cite an RFC or specification to contradict my
argument? I give you overwhelming and specific evidence of a bug, yet
you don't contradict even one of my statements. I am confident that you
can't.
Still I wait for an rebuttal with technical merit. I can justify every
single assertion that I have made and back them up with RFC,
specification, or common sense.
-Steve
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
See intermixed.
On Thu, 9 May 2002, Steve McCarthy wrote:
Date: Thu, 09 May 2002 15:44:30 -0700
From: Steve McCarthy [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: Prove me wrong - take this quiz
Remy Maucherat wrote:
Question 1
Does servlet specification require you to call flush() to ensure that
the client actually see the bytes?
A. No, spec does not mandate this behavior for webapps.
B. you have to flush your writer. Otherwise, because of timing
problems, the bytes will not get written (bug 8916)
If you instantiate a buffered writer yourself (instead of using
resp.getWriter)
to wrap around resp.getOutputStream, you have to flush it.
So it's B.
Wrong again, Remy. And please stop introducing diversions like
instantiating a buffered writer yourself. The bug exists with the
Writer returned from the container.
Please go the the Java Servlet Specification, v2.2 Final Release.
Where does it put the burden of flushing buffer on the web application?
Please cite the chapter and section. Of course you can't because it is
not there.
Why is Tomcat 4.0.x is the only servlet container that requires this
strange behavior? Old JServ didn't. WebLogic doesn't.
I don't see how a reasonable developer can not answer A.
Also, what is this business you said about because of timing problems,
the bytes will not get written? Do other developers agree with this
statement?
Being somewhat familiar with the servlet specs (I've been on the expert
groups for 2.2, 2.3, and 2.4 :-), the following two scenarios have the
potential to behave differently, depending on implementation-specific
decisions inside both the servlet container and the JDK:
(a) Write directly to ServletOutputStream:
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
ServletOutputStream sos = response.getOutputStream();
sos.print(foo);
// No flush on sos
}
}
(b) Write to a buffered wrapper around ServletOutputStream:
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
ServletOutputStream sos = response.getOutputStream();
BufferedOutputStream bos = new BufferedOutputStream(sos);
sos.print(foo);
// No flush on bos or sos
}
}
In scenario (a), the three characters will be written to the response --
the container flushes the container-provided stream for you.
In scenario (b), the three characters will *not* be written to the
response -- they are sitting inside the buffer in the
BufferedOutputStream, and are not accessible to the container -- it
doesn't even know that the wrapping class is there. You have to call
bos.flush() in order for them to be written. (Exactly the same issue is
true with all of the standard Java output objects - this is not specific
to servlet containers).
Scenario (b) is also a very common problem in a servlet 2.3 environment,
when you use a Filter to create a response wrapper (for instance, to do an
XSLT transformation on the output generated by the servlet. It is the
application's responsibility to ensure that the output stream or writer it
creates in the wrapper is indeed flushed before the filter returns.
Usually, that's just a matter of ensuring that you flush it after the
chain.doFilter() method returns, and before you yourself return from the
filter.
Steve, your original example in bug report 8916 is exactly analogous to
scenario (b), because you are creating a java.io.PrintWriter wrapper
around the ServletOutputStream provided by the container. It is entirely
legal for a java.io.PrintWriter implementation to buffer things up inside
itself -- programs that rely on this *not* happening are incorrect, even
if they happen to work in *some* environments.
Note also that it's entirely irrelevant whether ErrorReportValve is
involved or not -- user objects that wrap the container-provided stream or
writer *must* be flushed in order to guarantee that the output actually
gets written. Even if you had returned a status 200 (so that the error
reporting mechanism wasn't involved), you would not have seen the actual
character written by your test servlet.
I haven't looked at bug report 8831 yet, but 8916 is definitely an
application error.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Steve McCarthy [EMAIL PROTECTED] wrote: Hi, Developers and Developer-ettes! It is time for a fun quiz to test your knowledge of HTTP, Servlets, and servlet behavior. See if you can get them all right! As a bonus, see if you can guess how Tomcat handles these situations (as of 5/8/2002). Kewl, let's do this... Section 1 - HTTP - Question 1 HTTP 1.1 specification RFC 2616 defines 5 classes of status codes: 1xx, 2xx, 3xx, 4xx, and 5xx. What do the 2xx codes signify? A. Successful Hmm... A! Question 2 What 2xx status codes are defined by RFC 2616? A. 200 - 206 Hmm... A Question 3 If an HTTP application returns a 2xx code that is beyond the range of 2xx status codes, say 299, is it an error? A. No, it is by definition a success. Hmm... A Section 2 - Servlet Container behavior -- A servlet wants to write to the client. It sets the status code to 299. It obtains a PrintWriter from the servlet container and writes to it. Question 1 Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. Hmm... A Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. Hmm... A Question 3 The servlet spec allows you to write to the output by either obtaining a Writer or an OutputStream from the container, but not both. Should servlet container behave differently if application writes to OutputStream instead of Writer? A. No. Behavior should be consistent. Hmm... A Question 4 When is it ever acceptable to replace the content-type and message body when servlet is returning a 2xx status code? A. As a practical matter, it should never change the headers or body for any code less than 400. Hmm... A Section 3 - Guess the output The following code samples are assumed to be in a servlet's service() method. Sample Code 1 - response.setStatus(299); response.setContentType(application/x-pig-latin); response.getWriter().println(an-Cay ou-yay ead-ray is-thay?); Question 1 What should the client see in the Content-type header? A. application/x-pig-latin Hmm... A Question 2 What should the client see in the message body? A. The string an-Cay ou-yay ead-ray is-thay? Hmm... A Sample Code 2 - response.setStatus(299); response.setContentType(application/x-pig-latin); Writer w = response.getWriter(); w.println(an-Cay ou-yay ead-ray is-thay?); w.flush(); Question 3 What should the client see in the message body? A. The string an-Cay ou-yay ead-ray is-thay? Hmm... A Sample Code 3 - response.setStatus(299); response.setContentType(application/x-pig-latin); response.getOutputStream().write(an-Cay ou-yay ead-ray is-thay?.getBytes()); Question 4 What should the client see in the message body? A. The string an-Cay ou-yay ead-ray is-thay? Hmm... A ANSWERS: Of course, these are loaded questions. :) A is the correct answer to all of the questions, and the last choice for each question describes current Tomcat behavior. DOOH! So, I figured... Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. Hmm... A. I have been frustrated in multiple attempts to report this very glaring bug, because the reviewer chooses to close the bugs, dismissing them out-of-hand as invalid without addressing a single fact, without being able to muster a technical argument to where I might be mistaken. Hmm... A. Ehgeehehehmmm... Sorry... No, yes, indeed, I followed a little bit the stuff on 8831, that has been closed _4_ times, and goddamit, you're absolutely right, and 8916 has been closes _3_ times... Making it 7 times when a bug was closed for (FWICS) no good reason... I am pretty sure that I am solid on the specs, and would welcome technical feedback, backed by relevent spec or RFC, to the contrary. Yes you are... But you're not the only one to think that Tomcat's HTTP behavior is less than compliant to the spec in more than one critical aspect (the last one was pointed out today by JF, for example) plea Hoping for some help from committers who can see this behavior is wrong and needs to be changed./plea I agree that a patch must be provided and something shall be done to address an utterly irresponsible and mischievous behavior of ErrorReportValve. I can submit a patch if anyone is interested. That would be appropriate... (Ref: bugs 8831 and 8916.) I've seen the pain... Thanks for reading this far,
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: Question 1 Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) If you instantiate a buffered writer yourself (instead of using resp.getWriter) to wrap around resp.getOutputStream, you have to flush it. So it's B. But if I don't, then apparently the container is able to do anything he can with the written data, like /dev/null(ing) it... Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. If the servlet didn't do anything other that set headers, and did not write any content, it doesn't contrdict any spec, and is desirable if the client is a web browser. B also. Who gives a damn about web browsers? Cute'n fancy HTML, but a response status of 2xx means -it's-all-right-, and I _want_ my headers to go straight down back to the requestor... I had this problem with Tomcat and AvantGo trying to do my employer's PDA-enabled news site Question 3 The servlet spec allows you to write to the output by either obtaining a Writer or an OutputStream from the container, but not both. Should servlet container behave differently if application writes to OutputStream instead of Writer? A. No. Behavior should be consistent. B. If application returns 2xx other than 200 or 204, and it called getWriter(), then the response will be replaced, unless it has been committed via flush(), or if the application called getOutputStream(). A, and behavior IS consistent. All your examples from section 3 would work fine. They don't do the same thing as the invalid test case you attached to the report, in that they actually do write the bytes. I'll have to triplecheck this with my own eyes... I have been frustrated in multiple attempts to report this very glaring bug, because the reviewer chooses to close the bugs, dismissing them out-of-hand as invalid without addressing a single fact, without being able to muster a technical argument to where I might be mistaken. Your bug really is invalid, but you don't seem to be reading the comments. I believe that his bug is _really_ valid... From what I can see in the code http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/ apache/catalina/valves/ErrorReportValve.java?rev=1.5.2.3content-type=text/v nd.viewcvs-markup Scroll down 3/4 pages and go to the report method... That sucker only returns if statusCode 200, while to be correct, it should only do it if 300 (also I'd tend to consider the 400, so including redirection, not to have a magically generated body). Look at invoke, it's clearly glamorously there, if we didn't get the response committed, or an exception in the request, that valve _does_ take the underlying streams _and_ write out data... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
costin 02/05/09 16:46:33
Modified:jk/java/org/apache/jk/common JniHandler.java Shm.java
jk/java/org/apache/jk/server JkCoyoteHandler.java
Log:
Reduce verbosity
Revision ChangesPath
1.4 +2 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JniHandler.java
Index: JniHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JniHandler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JniHandler.java 25 Apr 2002 23:13:24 - 1.3
+++ JniHandler.java 9 May 2002 23:46:33 - 1.4
@@ -186,7 +186,7 @@
protected int nativeDispatch( Msg msg, MsgContext ep, int code )
throws IOException
{
-if( log.isInfoEnabled() ) log.info( Sending packet );
+if( log.isDebugEnabled() ) log.debug( Sending packet );
msg.end();
if( log.isTraceEnabled() ) msg.dump(OUT: );
long xEnv=ep.getJniEnv();
@@ -209,7 +209,7 @@
nativeContext,
code, msg.getBuffer(), msg.getLen());
-if( log.isInfoEnabled() ) log.info( Sending packet - done + status);
+if( log.isDebugEnabled() ) log.debug( Sending packet - done + status);
return status;
}
1.11 +1 -2 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java
Index: Shm.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Shm.java 9 May 2002 00:13:33 - 1.10
+++ Shm.java 9 May 2002 23:46:33 - 1.11
@@ -177,7 +177,6 @@
to identify tomcat.
*/
public void setUnregister( boolean unregister ) {
-System.out.println(XXX set unregister );
this.unregister=true;
}
@@ -333,7 +332,7 @@
throws IOException
{
if( apr==null ) return 0;
-System.err.println(ChannelShm.invoke: + ep );
+log.debug(ChannelShm.invoke: + ep );
super.nativeDispatch( msg, ep, JK_HANDLE_SHM_DISPATCH );
return 0;
}
1.19 +11 -10
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
Index: JkCoyoteHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- JkCoyoteHandler.java 25 Apr 2002 23:13:24 - 1.18
+++ JkCoyoteHandler.java 9 May 2002 23:46:33 - 1.19
@@ -172,7 +172,7 @@
// set the filters accordingly.
res.sendHeaders();
}
-if( log.isInfoEnabled() ) log.info(doWrite );
+if( log.isDebugEnabled() ) log.debug(doWrite );
MsgContext ep=(MsgContext)res.getNote( epNote );
MsgAjp msg=(MsgAjp)ep.getNote( headersMsgNote );
@@ -189,8 +189,8 @@
throws IOException
{
Response res=req.getResponse();
-if( log.isInfoEnabled() )
-log.info(doRead + chunk.getBytes() + + chunk.getOffset() +
+ chunk.getLength());
+if( log.isDebugEnabled() )
+log.debug(doRead + chunk.getBytes() + + chunk.getOffset() +
+ chunk.getLength());
MsgContext ep=(MsgContext)res.getNote( epNote );
JkInputStream jkIS=(JkInputStream)ep.getNote( inputStreamNote );
@@ -207,7 +207,8 @@
org.apache.coyote.Response res=req.getResponse();
res.setHook( this );
-log.info( Invoke + req + + res + + req.requestURI().toString());
+if( log.isDebugEnabled() )
+log.debug( Invoke + req + + res + +
req.requestURI().toString());
res.setOutputBuffer( this );
req.setInputBuffer( this );
@@ -233,8 +234,8 @@
private void appendHead(org.apache.coyote.Response res)
throws IOException
{
-if( log.isInfoEnabled() )
-log.info(COMMIT sending headers + res + + res.getMimeHeaders() );
+if( log.isDebugEnabled() )
+log.debug(COMMIT sending headers + res + + res.getMimeHeaders()
);
C2BConverter c2b=(C2BConverter)res.getNote( utfC2bNote );
if( c2b==null ) {
@@ -288,8 +289,8 @@
if( log.isInfoEnabled() )
log.info(RESET );
} else if( actionCode==ActionCode.ACTION_CLOSE ) {
-if( log.isInfoEnabled() )
-
cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c
costin 02/05/09 16:47:32
Modified:jk/native2/common jk_channel_socket.c jk_channel_un.c
jk_env.c jk_shm.c jk_workerEnv.c jk_worker_ajp13.c
jk_worker_lb.c
jk/native2/jni jk_jni_aprImpl.c
Log:
reduce verbosity.
Make sure we try all available workers before giving up.
Revision ChangesPath
1.23 +4 -2 jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
Index: jk_channel_socket.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- jk_channel_socket.c 9 May 2002 21:12:15 - 1.22
+++ jk_channel_socket.c 9 May 2002 23:47:31 - 1.23
@@ -276,8 +276,10 @@
/* Tries to connect to JServ (continues trying while error is EINTR) */
do {
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelSocket.open() connect on %d\n,sock);
+if( ch-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ channelSocket.open() connect on %d\n,sock);
+
ret = connect(sock,(struct sockaddr *)addr,
sizeof(struct sockaddr_in));
1.2 +22 -17jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c
Index: jk_channel_un.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_channel_un.c 9 May 2002 00:05:14 - 1.1
+++ jk_channel_un.c 9 May 2002 23:47:31 - 1.2
@@ -123,7 +123,7 @@
{
jk_channel_un_private_t *socketInfo=
(jk_channel_un_private_t *)(_this-_privatePtr);
-int rc;
+int rc=JK_OK;
if( socketInfo-file==NULL ) {
char *localName=_this-mbean-localName;
@@ -147,10 +147,10 @@
strcpy(socketInfo-unix_addr.sun_path, socketInfo-file );
env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelApr.resolve(): create AF_UNIX %s\n,
socketInfo-file );
+ channelUn.init(): create AF_UNIX %s\n, socketInfo-file );
} else {
-env-l-jkLog(env, env-l, JK_LOG_ERROR, jk2_channel_un_init:
- can't resolve %s errno=%d\n, socketInfo-file, errno );
+env-l-jkLog(env, env-l, JK_LOG_ERROR, channelUn.init():
+ can't init %s errno=%d\n, socketInfo-file, errno );
}
return rc;
@@ -175,8 +175,9 @@
return JK_ERR;
}
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelApr.open(): create unix socket %s %d\n,
socketInfo-file, unixsock );
+if( _this-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ channelApr.open(): create unix socket %s %d\n,
socketInfo-file, unixsock );
if (connect(unixsock,(struct sockaddr *)(socketInfo-unix_addr),
sizeof(struct sockaddr_un))0) {
@@ -186,8 +187,9 @@
errno, strerror( errno ) );
return JK_ERR;
}
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelApr.open(): connect unix socket %d %s\n, unixsock,
socketInfo-file );
+if( _this-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ channelApr.open(): connect unix socket %d %s\n, unixsock,
socketInfo-file );
/* store the channel information */
endpoint-sd=unixsock;
@@ -234,10 +236,11 @@
/* this_time = send(unixsock, (char *)b + sent , len - sent, 0); */
errno=0;
this_time = write(unixsock, (char *)b + sent , len - sent);
-
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- channel.apr:send() write() %d %d %s\n, this_time, errno,
- strerror( errno));
+
+if( _this-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ channel.apr:send() write() %d %d %s\n, this_time, errno,
+ strerror( errno));
/* if( errno != 0 ) { */
/* env-l-jkLog(env, env-l, JK_LOG_ERROR, */
/* channel.apr:send() send() %d %d %s\n, this_time,
errno, */
@@ -330,9 +333,10 @@
return JK_ERR;
}
-env-l-jkLog(env, env-l, JK_LOG_INFO,
- channelApr.receive(): Received len=%d type=%d\n,
- blen, (int)msg-buf[hlen]);
+if( _this-mbean-debug 0 )
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ channelApr.receive(): Received
Re: Prove me wrong - take this quiz
On Thu, 9 May 2002, Steve McCarthy wrote:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
Are you sure you are looking at the right source ? I'm pretty sure
the PrintWriter is doing the buffering - most likely in the Char2Byte
conversion.
I did a lot of work on this area and I'm pretty sure I'm right on this,
there is a 8k buffer for everything that converts ( at least in
all VMs I worked with ). Jad may help you locate it.
characters are not buffered Writer level. If there is any buffering, it
occurs in the OutputStream provided by the container, and is therefore
available to the container.
You can probably check this by putting yet another wrapper -
new PrintWriter ( new MyOutputStreamWrapper( res.getOutputStream()),
and in MyOSWrapper you insert println() before calling the real stream.
I can bet you won't get any data passed to the output stream.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
service(...) {
OutputStream os = response.getOutputStream();
byte arr[] = getBytes();
os.write(arr);
// no os.flush();
}
It is different - again, there is a buffer. If you don't trust me try
yourself or use a dissasembler ( the char-byte converters are in sun.io,
they don't have sources ).
By the way, wrapping the application-level PrintWriter around the
OutputStream was intended to show two things:
1. Be a really simple example.
2. Demonstrate an inconsistent behavior that was present in Tomcat
4.0.1 where, by obtaining an OutputStream, you prevented
ErrorReportValve from obtaining a Writer, and thereby avoided having
your data trashed. I think that behavior may have changed in 4.0.4 and
beyond.
I do agree ErrorReportValve has a bug and shouldn't touch the
response if 2xx status, but that's a different story.
If you use w=response.getWriter() than it should work without flush,
since the container does have access to the buffer ( in the first
case the container has no way to access your writer )
I agree that a 2xx response with empty content is perfectly valid
and shouldn't be modified, that's a bug.
What is your opinion about 3xx codes?
I think it would be good to not touch them - the user does have a way to
generate 'nice' messages ( using error-code in web.xml ).
But I don't think the spec explicitely forbids us to change the body
on 3xx. I would make this configurable at least.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
characters are not buffered Writer level. If there is any buffering,
it occurs in the OutputStream provided by the container, and is
therefore available to the container.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
It's funny, I was just looking at this yesterday because I was having a
problem similar to what you are describing.
from java.io.PrintWriter ( JDK1.40 ):
public PrintWriter(OutputStream out, boolean autoFlush) {
this(new BufferedWriter(new OutputStreamWriter(out)), autoFlush);
}
So yes, it is buffered :(.
-Dan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
[EMAIL PROTECTED] wrote: Are you sure you are looking at the right source ? I'm pretty sure the PrintWriter is doing the buffering - most likely in the Char2Byte conversion. I did a lot of work on this area and I'm pretty sure I'm right on this, there is a 8k buffer for everything that converts ( at least in all VMs I worked with ). Jad may help you locate it. Yep, you are right. PrintWriter internally wraps the supplied OutputStream with a BufferedWriter. Didn't see that the first time through. I do agree ErrorReportValve has a bug and shouldn't touch the response if 2xx status, but that's a different story. Well, that's what I really care about. What is your opinion about 3xx codes? I think it would be good to not touch them - the user does have a way to generate 'nice' messages ( using error-code in web.xml ). But I don't think the spec explicitely forbids us to change the body on 3xx. I would make this configurable at least. Sounds reasonable. -Steve -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Steve McCarthy [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Steve,
In 8916 - if you use:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
characters are not buffered Writer level. If there is any buffering, it
occurs in the OutputStream provided by the container, and is therefore
available to the container.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
service(...) {
OutputStream os = response.getOutputStream();
byte arr[] = getBytes();
os.write(arr);
// no os.flush();
}
Hmm... That actually (I tried it) works on 4.0.3 with the HTTP connector (I
have my doubts about Coyote, it simply crashes with an NPE)... Look:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Steve extends HttpServlet {
public void service(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException {
OutputStream os = res.getOutputStream();
byte arr[] = getBytes();
os.write(arr);
}
}
[pier@blossom] ~ $ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.betaversion.org.
Escape character is '^]'.
GET /servlet/Steve HTTP/1.1
Host: localhost:8080
Connection: close
HTTP/1.1 200 OK
Date: Fri, 10 May 2002 00:19:12 GMT
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
Connection: close
...Connection closed by foreign host.
[pier@blossom] ~ $
The problem _I_ had with AvantGo is the following: Given this _very_ stupid
but _very_ valid servlet:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Test extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException {
res.setStatus(302);
res.setContentLength(0);
res.setHeader(Location,http://www.vnunet.com/PDARedirected;);
}
}
Check out what the _hell_ does happen... (I'm doing it with keep alive so
you'll get the extent of the damage):
[pier@blossom] ~ $ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.betaversion.org.
Escape character is '^]'.
GET /servlet/Test HTTP/1.1
Host: localhost:8080
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Content-Length: 0
Date: Fri, 10 May 2002 00:25:16 GMT
Location: http://www.vnunet.com/PDARedirected
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;} B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 302 - Moved
Temporarily/h1HR size=1 noshadepbtype/b Status
report/ppbmessage/b uMoved
Temporarily/u/ppbdescription/b uThe requested resource (Moved
Temporarily) has moved temporarily to a new location./u/pHR size=1
noshade/body/htmlGET /servlet/Test HTTP/1.1
Host: localhost:8080
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Content-Length: 0
Date: Fri, 10 May 2002 00:25:24 GMT
Location: http://www.vnunet.com/PDARedirected
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;} B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 302 - Moved
Temporarily/h1HR size=1 noshadepbtype/b Status
report/ppbmessage/b uMoved
Temporarily/u/ppbdescription/b uThe requested resource (Moved
Temporarily) has moved temporarily to a new location./u/pHR size=1
noshade/body/html^]
telnet close
Connection closed.
[pier@blossom] ~ $
My servlet _says_ it's a 302, temporary redirect, my servlet _says_ the
content length is 0, my servlet doesn't touch even barely the stupid stream
because it got nothing to do with the sucker, and then, I still get back
some text, _AND_ the Content-Length saying that there MUST NOT BE...
This _screws_ up all my requests... Allloooffftthhhee... Keep alive is
dropped, and mess mess mess on all PDAs...
A I hate the ErrorReporterCrap...
Pier
--
I think that it's extremely foolish to name a server after the current U.S.
President. B.W. Fitzpatrick
--
To unsubscribe,
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: Question 1 Does servlet specification require you to call flush() to ensure that the client actually see the bytes? A. No, spec does not mandate this behavior for webapps. B. you have to flush your writer. Otherwise, because of timing problems, the bytes will not get written (bug 8916) If you instantiate a buffered writer yourself (instead of using resp.getWriter) to wrap around resp.getOutputStream, you have to flush it. So it's B. But if I don't, then apparently the container is able to do anything he can with the written data, like /dev/null(ing) it... A long time ago, it did I think. Now it doesn't. You can test it easily by using the HelloWorld servlet, and add a setStatus(250). Question 2 Where in servlet spec (or RFC 2616, your choice) does it allow the container to replace the message body or content-type header for an application that has set the status code to 2xx? A. It doesn't. It shouldn't. That would be clearly wrong. B. 200's and 204's are left alone, all other 2xx status codes are fair game to have their headers and body replaced. If the servlet didn't do anything other that set headers, and did not write any content, it doesn't contrdict any spec, and is desirable if the client is a web browser. B also. Who gives a damn about web browsers? Cute'n fancy HTML, but a response status of 2xx means -it's-all-right-, and I _want_ my headers to go straight down back to the requestor... Headers are not modified, except if the reponse was empty, content-type would be modified (but since it was empty, it seems irrelevant to me). I had this problem with Tomcat and AvantGo trying to do my employer's PDA-enabled news site Really ? What did it do ? Question 3 The servlet spec allows you to write to the output by either obtaining a Writer or an OutputStream from the container, but not both. Should servlet container behave differently if application writes to OutputStream instead of Writer? A. No. Behavior should be consistent. B. If application returns 2xx other than 200 or 204, and it called getWriter(), then the response will be replaced, unless it has been committed via flush(), or if the application called getOutputStream(). A, and behavior IS consistent. All your examples from section 3 would work fine. They don't do the same thing as the invalid test case you attached to the report, in that they actually do write the bytes. I'll have to triplecheck this with my own eyes... I don't think it would work ok with all 4.0.x versions. Obviously, I'm only testing with the most recent stuff (happened to be the 4.1.1+). But, yes, it works. I have been frustrated in multiple attempts to report this very glaring bug, because the reviewer chooses to close the bugs, dismissing them out-of-hand as invalid without addressing a single fact, without being able to muster a technical argument to where I might be mistaken. Your bug really is invalid, but you don't seem to be reading the comments. I believe that his bug is _really_ valid... From what I can see in the code http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/ apache/catalina/valves/ErrorReportValve.java?rev=1.5.2.3content-type=text/v nd.viewcvs-markup Scroll down 3/4 pages and go to the report method... That sucker only returns if statusCode 200, while to be correct, it should only do it if 300 (also I'd tend to consider the 400, so including redirection, not to have a magically generated body). Look at invoke, it's clearly glamorously there, if we didn't get the response committed, or an exception in the request, that valve _does_ take the underlying streams _and_ write out data... It's a bit more subtle than that, actually. You don't need to commit, just write something, as the valve uses getReporter, instead of getWriter to get the writer to write the data. If people feel uncomfortable with the current behavior (although I assure you, it shouldn't break anything), we can change to 300 (many 3xx need status reports; at least, Apache give status reports for a lot of them, so I thought it was wise to do the same). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Dan Sandberg [EMAIL PROTECTED] wrote:
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
characters are not buffered Writer level. If there is any buffering,
it occurs in the OutputStream provided by the container, and is
therefore available to the container.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
It's funny, I was just looking at this yesterday because I was having a
problem similar to what you are describing.
from java.io.PrintWriter ( JDK1.40 ):
public PrintWriter(OutputStream out, boolean autoFlush) {
this(new BufferedWriter(new OutputStreamWriter(out)), autoFlush);
}
So yes, it is buffered :(.
Yes, and autoflush actually means that's going to call flush in finalize()
so when the Garbage Collector runs, if I'm not wrong (not positive about JDK
1.4 because I don¹t use it)
Pier
--
I think that it's extremely foolish to name a server after the current U.S.
President. B.W. Fitzpatrick
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Steve McCarthy [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Steve,
In 8916 - if you use:
service() {
w= new PrintWriter( response.getOutputStream );
w.println(...)
}
If you don't flush, then you'll get no output.
That's not because of the servlet spec - but because of the way
PrintWriter works, it'll put your output in a buffer and that'll not be
written to the output stream.
Please note that the example uses a PrintWriter, and not a
BufferedWriter. Looking at the source of PrintWriter, all of the
println() methods write the data to the underlying OutputStream -
characters are not buffered Writer level. If there is any buffering, it
occurs in the OutputStream provided by the container, and is therefore
available to the container.
It isn't any different than obtaining the OutputStream from the
container, writing bytes to it, and then not calling flush on the
OutputStream:
service(...) {
OutputStream os = response.getOutputStream();
byte arr[] = getBytes();
os.write(arr);
// no os.flush();
}
Hmm... That actually (I tried it) works on 4.0.3 with the HTTP connector
(I
have my doubts about Coyote, it simply crashes with an NPE)... Look:
?
Which version of Coyote HTTP/1.1 are you using, and what is the error ?
Tomcat 4.1.0 / 4.1.1 works fine for me.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
[EMAIL PROTECTED] wrote: I did a lot of work on this area and I'm pretty sure I'm right on this, there is a 8k buffer for everything that converts ( at least in all VMs I worked with ). Jad may help you locate it. Yep, you are right. PrintWriter internally wraps the supplied OutputStream with a BufferedWriter. Didn't see that the first time through. I do agree ErrorReportValve has a bug and shouldn't touch the response if 2xx status, but that's a different story. Well, that's what I really care about. Ok, so if I change 200 to 300 we'll all be friends, and everything will be fine ? That looks like a good deal. You'll still have to fix your WebDAV servlet though. BTW, did you try using the TC WebDAV servlet or Slide instead of writing your own ? What is your opinion about 3xx codes? I think it would be good to not touch them - the user does have a way to generate 'nice' messages ( using error-code in web.xml ). But I don't think the spec explicitely forbids us to change the body on 3xx. I would make this configurable at least. Sounds reasonable. The configurability is tricky to add. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/netscape jk_nsapi_plugin.c
larryi 02/05/09 17:44:09
Modified:jk/native/netscape jk_nsapi_plugin.c
Log:
Finally port the input chunking changes from Tomcat 3.3.x
Revision ChangesPath
1.8 +34 -7 jakarta-tomcat-connectors/jk/native/netscape/jk_nsapi_plugin.c
Index: jk_nsapi_plugin.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/netscape/jk_nsapi_plugin.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_nsapi_plugin.c 29 Nov 2001 20:02:44 - 1.7
+++ jk_nsapi_plugin.c 10 May 2002 00:44:09 - 1.8
@@ -58,7 +58,7 @@
/***
* Description: NSAPI plugin for Netscape servers *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.7 $ *
+ * Version: $Revision: 1.8 $ *
***/
@@ -478,6 +478,8 @@
static int setup_http_headers(nsapi_private_data_t *private_data,
jk_ws_service_t *s)
{
+int need_content_length_header = (s-content_length == 0) ? JK_TRUE : JK_FALSE;
+
pblock *headers_jar = private_data-rq-headers;
int cnt;
int i;
@@ -490,9 +492,13 @@
}
}
+s-headers_names = NULL;
+s-headers_values = NULL;
+s-num_headers = cnt;
if(cnt) {
-s-headers_names = jk_pool_alloc(private_data-p, cnt * sizeof(char *));
-s-headers_values = jk_pool_alloc(private_data-p, cnt * sizeof(char *));
+/* allocate an extra header slot in case we need to add a content-length
header */
+s-headers_names = jk_pool_alloc(private_data-p, (cnt + 1) * sizeof(char
*));
+s-headers_values = jk_pool_alloc(private_data-p, (cnt + 1) * sizeof(char
*));
if(s-headers_names s-headers_values) {
for(i = 0, cnt = 0 ; i headers_jar-hsize ; i++) {
@@ -500,18 +506,39 @@
while(h h-param) {
s-headers_names[cnt] = h-param-name;
s-headers_values[cnt] = h-param-value;
+if(need_content_length_header
+!strncmp(h-param-name,content-length,14)) {
+need_content_length_header = JK_FALSE;
+}
cnt++;
h = h-next;
}
}
+/* Add a content-length = 0 header if needed.
+ * Ajp13 assumes an absent content-length header means an unknown,
+ * but non-zero length body.
+ */
+if(need_content_length_header) {
+s-headers_names[cnt] = content-length;
+s-headers_values[cnt] = 0;
+cnt++;
+}
s-num_headers = cnt;
return JK_TRUE;
}
} else {
-s-num_headers = cnt;
-s-headers_names = NULL;
-s-headers_values = NULL;
-return JK_TRUE;
+if (need_content_length_header) {
+s-headers_names = jk_pool_alloc(private_data-p, sizeof(char *));
+s-headers_values = jk_pool_alloc(private_data-p, sizeof(char *));
+if(s-headers_names s-headers_values) {
+s-headers_names[0] = content-length;
+s-headers_values[0] = 0;
+s-num_headers++;
+return JK_TRUE;
+}
+}
+else
+return JK_TRUE;
}
return JK_FALSE;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Steve McCarthy [EMAIL PROTECTED] wrote:
public class MyServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
ServletOutputStream sos = response.getOutputStream();
sos.setStatus(299);// - here
sos.print(foo);
// No flush on sos
}
}
[pier@blossom] ~ $ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.betaversion.org.
Escape character is '^]'.
GET /servlet/MyServlet HTTP/1.0
HTTP/1.1 299 HTTP Response Status 299
Date: Fri, 10 May 2002 00:33:01 GMT
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
Connection: close
fooConnection closed by foreign host.
[pier@blossom] ~ $
Again, this is what I see on MacOS/X with 4.0.3 and the HTTP/1.1 default
connector... The current Coyote HTTP adapter also works, and actually fixes
the behavior I observed with 302 when Content-Length is set manually to 0.
Pier
--
I think that it's extremely foolish to name a server after the current U.S.
President. B.W. Fitzpatrick
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2
Mr Chung,
On Thu, 9 May 2002, Kin-Man Chung wrote:
Denis,
One way to get rid of BidSet is to keep the state of things that needs to
be done in the (now virtual) finally block. Since the try blocks are
properly nested, it is sufficient to increment the state when entering
a try block, and to decrement it when exiting a try block. Something
like:
int state = 0;
// try {// 1st try
++state;
...
// try {// 2nd try
++state;
;;;
// }// end of 2nd try
--state;
// try {// 3rd try
++state;
;;;
// }// end of 2nd try
--state;
// }// end of 1st try
Then in finallies, you can do
if (state = 1 state = 3) {
if (state == 2) {
// do finally for 2nd try
} else if (state == 3) {
// do finally for the 3rd try
}
// do finally for 1st try
}
and so forth. I think it would be faster than using bitset.
To avoid using a Vector, you can try inlining finallies in _jspService
method. The compiler needs to keep track of what needs to be done
at the finally blocks for each of the state, but we don't need to do
any of the Vector operations at all, a big performance gain. If you
insist on having a separate finallies, then you can still pass all the
objects it needs to it as arguments.
In is now possible in jasper2 to scan the nodes for the page and collection
infos on the page (that's what PageInfo class is for), and the compiler
only needs to generate codes that is really necessary. For instance,
the generation of the method addTagToVector can be ommited when there is no
custom tag action in the page. I can add such info in PageInfo, now
that there is a use.
Comments?
Good idea, but I think it would be hard to accomplish as presented. Look again
at your pseudo-code:
int state = 0;
// try {// 1st try
++state;
...
// try {// 2nd try
++state;
;;;
// }// end of 2nd try
--state;
// try {// 3rd try
++state;
;;;
// }// end of 2nd try
--state;
// }// end of 1st try
You'll notice that both state 2 and state 3 have the value 2 assigned to the
state variable. What is complex here, is that it is hard to find a generic
way to represent all the states possible. Sometimes the states are nested,
like the first with the 2nd and 3rd. Sometimes the states follow one another,
like the second and third.
But there is surely something to do. Suppose we assign distinct values to
the state variable at each step where we enter a pseudo try and a
pseudo finally. Then, theoritically, it should be possible to determine
in the finallies method, just by looking at the value of the state variable
what remains to do. The problem could be to do it in exactly the same order
that would have been done if the page would have nested try/finally clauses.
If we look at what we have to do in the finallies method, we have essentially
two types of method call. Either the popBody() or the release() of a Tag.
I'm certainly not expert enough with the JSP specs to take a decision. Is it
critical that we call the release() of the tags in the proper order, if all
what's left to do is release() calls? What about the popBody()?
If we could do the popBody() calls out of order, say after all the release()
have been called, then the case of the popBody() is easy to deal with. We
just have to increment a counter for each pushBody() calls and decrement
it after each popBody() calls. In the finallies method we only have to
call popBody() the number of times the value of the counter. If so, the
state variable would only to have to represent the different combinations that
the tags doStartTag() have been called and if their respective release()
have been called.
I'm a little cautious about inlining the finallies method, because of
java's 64K per method limitation. One of the first pass of my test JSP did
generate over 64K in the _jsp_service method, so it generated an Invalid
branch exception or something named like that. Once I removed a few tags,
the page worked fine. It's easy to bypass by JSP include, but some people
might find the message cryptic (it is!), to determine what's exactly the
problem. The _jsp_service method can be really long, even without the
finallies being inlined. That's why I had created a new method.
Your idea of getting information from the PageInfo is certainly welcome. This
way we could prevent the creation of the finallies method and
addTagToVector. We could even replace the Vector by an Array that could be
allocated to the proper size at the start of the method. It would
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: If people feel uncomfortable with the current behavior (although I assure you, it shouldn't break anything), we can change to 300 (many 3xx need status reports; at least, Apache give status reports for a lot of them, so I thought it was wise to do the same). I don't feel unconfortable until the AvantGo people don't call me up saying that I'm screwing their whole HTTP stack. Coyote's 1.0-b8 actually fixes that problem, I figured that out tonight in a rage of testing HTTPs but it's damn broken in 4.0.4-b2 (NPEs following). I should have tried that out first... I'd be more confortable though if we didn't touch anything below 400... Pier (NPE following now) ERROR] Http11Processor - -Error finishing response java.lang.NullPointerException java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav a:583) at org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffe r.java:411) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.jav a:720) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:391) at org.apache.coyote.Response.action(Response.java:205) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.j ava:498) at org.apache.coyote.Response.doWrite(Response.java:466) at org.apache.coyote.tomcat4.OutputBuffer.realWriteBytes(OutputBuffer.java:380) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:360) at org.apache.coyote.tomcat4.OutputBuffer.flush(OutputBuffer.java:341) at java.io.PrintWriter.flush(PrintWriter.java:120) at org.apache.coyote.tomcat4.CoyoteWriter.flush(CoyoteWriter.java:97) at org.apache.catalina.valves.ErrorReportValve.report(ErrorReportValve.java:362 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:202 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.coyote.tomcat4.CoyoteProcessor.service(CoyoteProcessor.java:313) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:331) at org.apache.coyote.tomcat4.CoyoteProcessor.process(CoyoteProcessor.java:791) at org.apache.coyote.tomcat4.CoyoteProcessor.run(CoyoteProcessor.java:870) at java.lang.Thread.run(Thread.java:496) java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav a:583) at org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffe r.java:411) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.jav a:720) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:391) at org.apache.coyote.Response.action(Response.java:205) at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffe r.java:358) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:354) at org.apache.coyote.tomcat4.CoyoteProcessor.process(CoyoteProcessor.java:791) at org.apache.coyote.tomcat4.CoyoteProcessor.run(CoyoteProcessor.java:870) at java.lang.Thread.run(Thread.java:496) -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
The problem _I_ had with AvantGo is the following: Given this _very_
stupid
but _very_ valid servlet:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class Test extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException {
res.setStatus(302);
res.setContentLength(0);
res.setHeader(Location,http://www.vnunet.com/PDARedirected;);
}
}
Check out what the _hell_ does happen... (I'm doing it with keep alive so
you'll get the extent of the damage):
[pier@blossom] ~ $ telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.betaversion.org.
Escape character is '^]'.
GET /servlet/Test HTTP/1.1
Host: localhost:8080
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Content-Length: 0
Date: Fri, 10 May 2002 00:25:16 GMT
Location: http://www.vnunet.com/PDARedirected
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;} B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 302 - Moved
Temporarily/h1HR size=1 noshadepbtype/b Status
report/ppbmessage/b uMoved
Temporarily/u/ppbdescription/b uThe requested resource (Moved
Temporarily) has moved temporarily to a new location./u/pHR size=1
noshade/body/htmlGET /servlet/Test HTTP/1.1
Host: localhost:8080
HTTP/1.1 302 Moved Temporarily
Content-Type: text/html
Content-Length: 0
Date: Fri, 10 May 2002 00:25:24 GMT
Location: http://www.vnunet.com/PDARedirected
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
htmlheadtitleApache Tomcat/4.0.3 - Error
report/titleSTYLE!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;} B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --/STYLE
/headbodyh1Apache Tomcat/4.0.3 - HTTP Status 302 - Moved
Temporarily/h1HR size=1 noshadepbtype/b Status
report/ppbmessage/b uMoved
Temporarily/u/ppbdescription/b uThe requested resource (Moved
Temporarily) has moved temporarily to a new location./u/pHR size=1
noshade/body/html^]
telnet close
Connection closed.
[pier@blossom] ~ $
My servlet _says_ it's a 302, temporary redirect, my servlet _says_ the
content length is 0, my servlet doesn't touch even barely the stupid
stream
because it got nothing to do with the sucker, and then, I still get back
some text, _AND_ the Content-Length saying that there MUST NOT BE...
This _screws_ up all my requests... Allloooffftthhhee... Keep alive is
dropped, and mess mess mess on all PDAs...
A I hate the ErrorReporterCrap...
Yes, it's horrible. Given the way the old HTTP/1.1 connector is written it's
very hard and very risky to fix :-(
Use Coyote instead for deperate situations ;-)
At least, one version which doesn't throw a NPE (I suppose it does help).
I tried the example you mentioned above and your nasty 302 AvantGo
servlet, and both work fine in 4.1.1 (and 4.1.0 probably).
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: If people feel uncomfortable with the current behavior (although I assure you, it shouldn't break anything), we can change to 300 (many 3xx need status reports; at least, Apache give status reports for a lot of them, so I thought it was wise to do the same). I don't feel unconfortable until the AvantGo people don't call me up saying that I'm screwing their whole HTTP stack. Coyote's 1.0-b8 actually fixes that problem, I figured that out tonight in a rage of testing HTTPs but it's damn broken in 4.0.4-b2 (NPEs following). I should have tried that out first... I'd be more confortable though if we didn't touch anything below 400... Pier (NPE following now) ERROR] Http11Processor - -Error finishing response java.lang.NullPointerException java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav a:583) at org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffe r.java:411) Well, yeah, that's a stupid NPE, which happens whenever the message text is null. When you call sendError(456, Arg, broken) it worked, but using setStatus(456) left it null, which caused the bug. Easy fix :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: Yes, it's horrible. Given the way the old HTTP/1.1 connector is written it's very hard and very risky to fix :-( As long as 4.0.4 will work... I'd like to see either that fixed, or a working replacement with Coyote. Use Coyote instead for deperate situations ;-) At least, one version which doesn't throw a NPE (I suppose it does help). 1.0b8 works under 4.0.3. No problems but NIP (not in production) I tried the example you mentioned above and your nasty 302 AvantGo servlet, and both work fine in 4.1.1 (and 4.1.0 probably). It's not nasty it's perfectly fine... To go in production I added a response.flushBuffer() at the end so that it fixed the behavior, but I shouldn't have to do that... Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: Easy fix :) Then fixit, dammit. :) Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: Yes, it's horrible. Given the way the old HTTP/1.1 connector is written it's very hard and very risky to fix :-( As long as 4.0.4 will work... I'd like to see either that fixed, or a working replacement with Coyote. You'll have the working replacement for tricky situations. Fixing it would likely mean breaking more things (no, I didn't rewrite the thing because I was bored). I would plan on trying to use 4.1.x if I were you, though. Use Coyote instead for deperate situations ;-) At least, one version which doesn't throw a NPE (I suppose it does help). 1.0b8 works under 4.0.3. No problems but NIP (not in production) Yes, I understand. I tried the example you mentioned above and your nasty 302 AvantGo servlet, and both work fine in 4.1.1 (and 4.1.0 probably). It's not nasty it's perfectly fine... Sorry, I misquoted you, you actually called it stupid ;-) To go in production I added a response.flushBuffer() at the end so that it fixed the behavior, but I shouldn't have to do that... Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs class-loader-howto.xml
pier02/05/09 18:15:59
Modified:catalina build.xml
webapps/tomcat-docs class-loader-howto.xml
Log:
Committing change to rename tomcat-webapp.jar to tomcat-warp.jar as
posted last week on the mailing list.
Revision ChangesPath
1.115 +3 -3 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -r1.114 -r1.115
--- build.xml 25 Apr 2002 14:12:07 - 1.114
+++ build.xml 10 May 2002 01:15:59 - 1.115
@@ -39,8 +39,8 @@
value=${tomcat-jk.home}/build/lib/tomcat-jni.jar/
property name=jk2.properties
value=${tomcat-jk.home}/build/conf/jk2.properties/
- property name=tomcat-webapp.jar
- value=${tomcat-webapp.home}/build/lib/tomcat-webapp.jar/
+ property name=tomcat-warp.jar
+ value=${tomcat-webapp.home}/build/lib/tomcat-warp.jar/
property name=tomcat-http11.jar
value=${tomcat-http11.home}/build/lib/tomcat-http11.jar/
@@ -879,7 +879,7 @@
/ant
copy todir=${catalina.deploy}/server/lib
- file=${tomcat-webapp.jar}/
+ file=${tomcat-warp.jar}/
/target
1.7 +4 -3 jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml
Index: class-loader-howto.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- class-loader-howto.xml14 Feb 2002 07:06:35 - 1.6
+++ class-loader-howto.xml10 May 2002 01:15:59 - 1.7
@@ -156,9 +156,10 @@
run behind web servers such as Apache and iPlanet iAS and iWS./li
liemtomcat-util.jar/em - Utility classes required by some
Tomcat connectors./li
-liemtomcat-webapp.jar/em - Classes for the Java portion of the
-codeWebapp/code web server connector, which allows Tomcat to
-run behind web servers such as Apache and iPlanet iAS and iWS./li
+liemtomcat-warp.jar/em - Classes for the Java portion of the
+codeWebapp/code web server connector, using the WARP protocol
+which allows Tomcat to run behind the Apache HTTPD web server
+(1.3 and 2.0)./li
/ul/li
listrongShared/strong - This class loader is the place to put classes
and resources that you wish to share across strongALL/strong
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/webapp build.xml
pier02/05/09 18:16:38
Modified:webapp build.xml
Log:
Committing change to rename tomcat-webapp.jar to tomcat-warp.jar as
posted last week on the mailing list.
(still need to hammer down this file reducing it to a manageable state)
Revision ChangesPath
1.6 +2 -2 jakarta-tomcat-connectors/webapp/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/build.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- build.xml 5 May 2002 03:30:42 - 1.5
+++ build.xml 10 May 2002 01:16:38 - 1.6
@@ -3,7 +3,7 @@
!--
Coyote connector framework for Jakarta Tomcat
-$Id: build.xml,v 1.5 2002/05/05 03:30:42 pier Exp $
+$Id: build.xml,v 1.6 2002/05/10 01:16:38 pier Exp $
--
@@ -158,7 +158,7 @@
copytodir=${build.home}/classes filtering=on
fileset dir=${source.home} excludes=**/*.java/
/copy
-jarjarfile=${build.home}/lib/tomcat-${component.name}.jar
+jarjarfile=${build.home}/lib/tomcat-warp.jar
basedir=${build.home}/classes /
/target
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
Remy Maucherat [EMAIL PROTECTED] wrote: You'll have the working replacement for tricky situations. Fixing it would likely mean breaking more things (no, I didn't rewrite the thing because I was bored). I would plan on trying to use 4.1.x if I were you, though. I got my priorities layered down right now: 1) Make sure my employer is happy not running alpha software in production 2) Feed and pet the cat 3) Find girlfriend (yeah, right) 4) Tease Jon 5) Make mod_webapp happy 6) try out tomcat 4.1 It's not nasty it's perfectly fine... Sorry, I misquoted you, you actually called it stupid ;-) It's a 3 lines servlet, how would you want to call it? Pier -- I think that it's extremely foolish to name a server after the current U.S. President. B.W. Fitzpatrick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2
See intermixed.
Date: Thu, 09 May 2002 20:48:27 -0400 (EDT)
From: Denis Benoit [EMAIL PROTECTED]
Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by
Jasper2
Good idea, but I think it would be hard to accomplish as presented. Look
again
at your pseudo-code:
int state = 0;
// try {// 1st try
++state;
...
// try {// 2nd try
++state;
;;;
// }// end of 2nd try
--state;
// try {// 3rd try
++state;
;;;
// }// end of 2nd try
--state;
// }// end of 1st try
You'll notice that both state 2 and state 3 have the value 2 assigned to the
state variable. What is complex here, is that it is hard to find a generic
way to represent all the states possible. Sometimes the states are nested,
like the first with the 2nd and 3rd. Sometimes the states follow one another,
like the second and third.
I realized my mistake as soon as I sent it out. :-)
But there is surely something to do. Suppose we assign distinct values to
the state variable at each step where we enter a pseudo try and a
pseudo finally. Then, theoritically, it should be possible to determine
in the finallies method, just by looking at the value of the state variable
what remains to do. The problem could be to do it in exactly the same order
that would have been done if the page would have nested try/finally clauses.
If we have distinct values for each state, theorectically we can implement
a state transition machine in the finallies. Something like the following.
while (state 0) {
switch (state) {
case 0: ...
state = 3; break; // goto state 3
case 1:
state = 13; break; // goto state 13
...
case 10: ...
state = -1; break // stop
}
}
This way we can specify any sequence we want. Of course there are various
optimizations that one can do here, but I won't go into them here.
If we look at what we have to do in the finallies method, we have
essentially
two types of method call. Either the popBody() or the release() of a Tag.
I'm certainly not expert enough with the JSP specs to take a decision. Is it
critical that we call the release() of the tags in the proper order, if all
what's left to do is release() calls? What about the popBody()?
popBody() simulates popping stacks, and has to be called in order.
If we could do the popBody() calls out of order, say after all the
release()
have been called, then the case of the popBody() is easy to deal with. We
just have to increment a counter for each pushBody() calls and decrement
it after each popBody() calls. In the finallies method we only have to
call popBody() the number of times the value of the counter. If so, the
state variable would only to have to represent the different combinations that
the tags doStartTag() have been called and if their respective release()
have been called.
Unfortunately we cannot call release() before calling popBody(), because
popBody() may use resources released by release(). (I'll need to check
that).
I'm a little cautious about inlining the finallies method, because of
java's 64K per method limitation. One of the first pass of my test JSP did
generate over 64K in the _jsp_service method, so it generated an Invalid
branch exception or something named like that. Once I removed a few tags,
the page worked fine. It's easy to bypass by JSP include, but some people
might find the message cryptic (it is!), to determine what's exactly the
problem. The _jsp_service method can be really long, even without the
finallies being inlined. That's why I had created a new method.
There maybe other ways to branch out part of the code in _jspService to
a method. I am considering moving the body of a tag that does not have
scriptlets out; but that's just a thought at this moments.
Even if we do keep finallies, it may worth looking into passing all the
necessary objects as arguments to it, instead of putting them in a Vector,
at least for the case with samll number of states. I think VM spec allows
256 arguments to a method. :-) We want to avoid unnecessay codes in
the main flow, but can afford to work harder when exceptions occur.
Your idea of getting information from the PageInfo is certainly welcome. This
way we could prevent the creation of the finallies method and
addTagToVector. We could even replace the Vector by an Array that could be
allocated to the proper size at the start of the method. It would prevent to
have to cope with the expansion of a Vector. Your idea of the state
variable,
merit more thought. There may be a way to use it.
Collecting information to PageInfo requires a speparate pass prior to
code
Re: Prove me wrong - take this quiz
On Fri, 2002-05-10 at 11:20, Pier Fumagalli wrote: I got my priorities layered down right now: 1) Make sure my employer is happy not running alpha software in production 2) Feed and pet the cat 3) Find girlfriend (yeah, right) 4) Tease Jon 5) Make mod_webapp happy 6) try out tomcat 4.1 As I said before, we'd have no fun on this list without Pier. On ya mate! Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
PATCH: DbcpDataSourceFactory
The DataSource factory wasn't setting maxIdle, and was incorrectly
setting maxActive
on the connection pool. This fixes it:
Michael
Index: DbcpDataSourceFactory.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java,v
retrieving revision 1.4
diff -u -r1.4 DbcpDataSourceFactory.java
--- DbcpDataSourceFactory.java 26 Dec 2001 01:22:10 - 1.4
+++ DbcpDataSourceFactory.java 10 May 2002 02:23:17 -
@@ -248,7 +248,7 @@
}
try {
if (maxIdle != null)
-connectionPool.setMaxActive(Integer.parseInt(maxIdle));
+connectionPool.setMaxIdle(Integer.parseInt(maxIdle));
} catch (Throwable t) {
log(Error setting maxIdle, t);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
remm02/05/09 20:02:25 Modified:catalina/src/share/org/apache/catalina/valves ErrorReportValve.java Log: - Don't output error reports for all 1xx and 2xx status codes. Revision ChangesPath 1.10 +6 -15 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java Index: ErrorReportValve.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- ErrorReportValve.java 24 Jan 2002 16:47:58 - 1.9 +++ ErrorReportValve.java 10 May 2002 03:02:25 - 1.10 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.9 2002/01/24 16:47:58 remm Exp $ - * $Revision: 1.9 $ - * $Date: 2002/01/24 16:47:58 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.10 2002/05/10 03:02:25 remm Exp $ + * $Revision: 1.10 $ + * $Date: 2002/05/10 03:02:25 $ * * * @@ -105,7 +105,7 @@ * @author Craig R. McClanahan * @author a href=mailto:[EMAIL PROTECTED];Nicola Ken Barozzi/a Aisa * @author a href=mailto:[EMAIL PROTECTED];Stefano Mazzocchi/a - * @version $Revision: 1.9 $ $Date: 2002/01/24 16:47:58 $ + * @version $Revision: 1.10 $ $Date: 2002/05/10 03:02:25 $ */ public class ErrorReportValve @@ -249,17 +249,8 @@ if (message == null) message = ; -// Do nothing on a 1xx status -if (statusCode 200) -return; -// Do nothing on an OK status -if (statusCode == HttpServletResponse.SC_OK) -return; -// Do nothing on a NOT MODIFIED status -if (statusCode == HttpServletResponse.SC_NOT_MODIFIED) -return; -// Do nothing on a NO CONTENT status -if (statusCode == HttpServletResponse.SC_NO_CONTENT) +// Do nothing on a 1xx and 2xx status +if (statusCode 300) return; // FIXME: Reset part of the request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2
Kim,
On Thu, 9 May 2002, Kin-Man Chung wrote:
If we have distinct values for each state, theorectically we can implement
a state transition machine in the finallies. Something like the following.
while (state 0) {
switch (state) {
case 0: ...
state = 3; break; // goto state 3
case 1:
state = 13; break; // goto state 13
...
case 10: ...
state = -1; break // stop
}
}
Yes, that could be some thing to implement, when generating the code for a
state we have to know two things, the state itself, and the next state, it
may very well be possible.
Thinking about it, I think this is a feature that we could take advantage from.
Whenever we hit a state, the next state is determined and so on.
The more I look at it, the more it looks like a state machine. Then, why not
implement it as a regular state machine in an array? We could build a static
array at compile time, and just modify a state variable at run time that
represent the index in the array. Then, if an exception occurs, we would only
have to apply the state to the static array to find out what we have to do.
I definitively need to think more about it, but it seems that we have something
here.
There maybe other ways to branch out part of the code in _jspService to
a method. I am considering moving the body of a tag that does not have
scriptlets out; but that's just a thought at this moments.
Even if we do keep finallies, it may worth looking into passing all the
necessary objects as arguments to it, instead of putting them in a Vector,
at least for the case with samll number of states. I think VM spec allows
256 arguments to a method. :-) We want to avoid unnecessay codes in
the main flow, but can afford to work harder when exceptions occur.
What about keeping a reference to the elements in an array? Assignment to
an array element is not very costly. We could even use the array elements
themselves instead of creating distinct variables for each tag.
If we do it this way, it can very well pave the way to reuse elements in
the same page. Whenever we call release() on a Tag, instead of allocating
a new tag of the same type, we could reuse the tag, no? I thought that the
specs allowed optimization of this sort?
If we have an array of tags, then the array of the state machine begins to
take form. We could have four columns in the array (either objects to
hold the 4 data elements, or four distinct arrays).
The index of the array would be the state, the first element of the row
would be the next state (-1) for done. The second element of the row
would be the action to perform, either release() or popBody(), and
the last element of the row would be the index in the Tag array to apply
the action to (only meaningful for release()).
The state array is final static, built at compile time and never modified
for a given JSP, so thread safe. The finallies method would only have to
loop thru the states and apply the action to the tags.
I need to think more about it, but it's starting to take form.
What do you think about it?
--
Denis Benoit
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory DbcpDataSourceFactory.java
remm02/05/09 20:08:35
Modified:catalina/src/share/org/apache/naming/factory
DbcpDataSourceFactory.java
Log:
- Fix cut paste bug where maxIdle wouldn't be set (instead, maxActive would
get the maxIdle value).
- Patch submitted by Michael Smith msmith at xn.com.au
Revision ChangesPath
1.5 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java
Index: DbcpDataSourceFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DbcpDataSourceFactory.java26 Dec 2001 01:22:10 - 1.4
+++ DbcpDataSourceFactory.java10 May 2002 03:08:35 - 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java,v
1.4 2001/12/26 01:22:10 glenn Exp $
- * $Revision: 1.4 $
- * $Date: 2001/12/26 01:22:10 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java,v
1.5 2002/05/10 03:08:35 remm Exp $
+ * $Revision: 1.5 $
+ * $Date: 2002/05/10 03:08:35 $
*
*
*
@@ -114,7 +114,7 @@
* /ul
*
* @author Craig R. McClanahan
- * @version $Revision: 1.4 $ $Date: 2001/12/26 01:22:10 $
+ * @version $Revision: 1.5 $ $Date: 2002/05/10 03:08:35 $
*/
public class DbcpDataSourceFactory
@@ -248,7 +248,7 @@
}
try {
if (maxIdle != null)
-connectionPool.setMaxActive(Integer.parseInt(maxIdle));
+connectionPool.setMaxIdle(Integer.parseInt(maxIdle));
} catch (Throwable t) {
log(Error setting maxIdle, t);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
remm02/05/09 20:20:58 Modified:catalina/src/share/org/apache/catalina/valves Tag: tomcat_40_branch ErrorReportValve.java Log: - Port patch. - Don't output error reports for all 1xx and 2xx status codes. Revision ChangesPath No revision No revision 1.5.2.4 +5 -14 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java Index: ErrorReportValve.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v retrieving revision 1.5.2.3 retrieving revision 1.5.2.4 diff -u -r1.5.2.3 -r1.5.2.4 --- ErrorReportValve.java 24 Jan 2002 22:52:31 - 1.5.2.3 +++ ErrorReportValve.java 10 May 2002 03:20:58 - 1.5.2.4 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.5.2.3 2002/01/24 22:52:31 remm Exp $ - * $Revision: 1.5.2.3 $ - * $Date: 2002/01/24 22:52:31 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.5.2.4 2002/05/10 03:20:58 remm Exp $ + * $Revision: 1.5.2.4 $ + * $Date: 2002/05/10 03:20:58 $ * * * @@ -104,7 +104,7 @@ * @author Craig R. McClanahan * @author a href=mailto:[EMAIL PROTECTED];Nicola Ken Barozzi/a Aisa * @author a href=mailto:[EMAIL PROTECTED];Stefano Mazzocchi/a - * @version $Revision: 1.5.2.3 $ $Date: 2002/01/24 22:52:31 $ + * @version $Revision: 1.5.2.4 $ $Date: 2002/05/10 03:20:58 $ */ public class ErrorReportValve @@ -248,16 +248,7 @@ message = ; // Do nothing on a 1xx status -if (statusCode 200) -return; -// Do nothing on an OK status -if (statusCode == HttpServletResponse.SC_OK) -return; -// Do nothing on a NO MODIFIED status -if (statusCode == HttpServletResponse.SC_NOT_MODIFIED) -return; -// Do nothing on a NO CONTENT status -if (statusCode == HttpServletResponse.SC_NO_CONTENT) +if (statusCode 300) return; // FIXME: Reset part of the request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
-// Do nothing on a NOT MODIFIED status -if (statusCode == HttpServletResponse.SC_NOT_MODIFIED) -return; This is actually 304. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
remm02/05/09 20:41:13 Modified:catalina/src/share/org/apache/catalina/valves ErrorReportValve.java Log: - Don't generate a status report for 304. Revision ChangesPath 1.11 +7 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java Index: ErrorReportValve.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- ErrorReportValve.java 10 May 2002 03:02:25 - 1.10 +++ ErrorReportValve.java 10 May 2002 03:41:13 - 1.11 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.10 2002/05/10 03:02:25 remm Exp $ - * $Revision: 1.10 $ - * $Date: 2002/05/10 03:02:25 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.11 2002/05/10 03:41:13 remm Exp $ + * $Revision: 1.11 $ + * $Date: 2002/05/10 03:41:13 $ * * * @@ -105,7 +105,7 @@ * @author Craig R. McClanahan * @author a href=mailto:[EMAIL PROTECTED];Nicola Ken Barozzi/a Aisa * @author a href=mailto:[EMAIL PROTECTED];Stefano Mazzocchi/a - * @version $Revision: 1.10 $ $Date: 2002/05/10 03:02:25 $ + * @version $Revision: 1.11 $ $Date: 2002/05/10 03:41:13 $ */ public class ErrorReportValve @@ -251,6 +251,9 @@ // Do nothing on a 1xx and 2xx status if (statusCode 300) +return; +// Do nothing on a NOT MODIFIED status +if (statusCode == HttpServletResponse.SC_NOT_MODIFIED) return; // FIXME: Reset part of the request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
-// Do nothing on a NOT MODIFIED status -if (statusCode == HttpServletResponse.SC_NOT_MODIFIED) -return; This is actually 304. Great catch. Thanks ! Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
remm02/05/09 20:43:52 Modified:catalina/src/share/org/apache/catalina/valves Tag: tomcat_40_branch ErrorReportValve.java Log: - Port patch. - Don't generate a status report for 304. - Submitted by Bill Barker. Revision ChangesPath No revision No revision 1.5.2.5 +7 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java Index: ErrorReportValve.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v retrieving revision 1.5.2.4 retrieving revision 1.5.2.5 diff -u -r1.5.2.4 -r1.5.2.5 --- ErrorReportValve.java 10 May 2002 03:20:58 - 1.5.2.4 +++ ErrorReportValve.java 10 May 2002 03:43:52 - 1.5.2.5 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.5.2.4 2002/05/10 03:20:58 remm Exp $ - * $Revision: 1.5.2.4 $ - * $Date: 2002/05/10 03:20:58 $ + * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v 1.5.2.5 2002/05/10 03:43:52 remm Exp $ + * $Revision: 1.5.2.5 $ + * $Date: 2002/05/10 03:43:52 $ * * * @@ -104,7 +104,7 @@ * @author Craig R. McClanahan * @author a href=mailto:[EMAIL PROTECTED];Nicola Ken Barozzi/a Aisa * @author a href=mailto:[EMAIL PROTECTED];Stefano Mazzocchi/a - * @version $Revision: 1.5.2.4 $ $Date: 2002/05/10 03:20:58 $ + * @version $Revision: 1.5.2.5 $ $Date: 2002/05/10 03:43:52 $ */ public class ErrorReportValve @@ -249,6 +249,9 @@ // Do nothing on a 1xx status if (statusCode 300) +return; +// Do nothing on a NOT MODIFIED status +if (statusCode == HttpServletResponse.SC_NOT_MODIFIED) return; // FIXME: Reset part of the request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
