DO NOT REPLY [Bug 28196] - forEach throws with arrays (${header}, ${param}, etc.)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28196.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28196
forEach throws with arrays (${header}, ${param}, etc.)
--- Additional Comments From [EMAIL PROTECTED] 2004-04-06 06:00 ---
Created an attachment (id=11149)
JSP source to reproduce the bug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28196] - forEach throws with arrays (${header}, ${param}, etc.)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28196.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28196
forEach throws with arrays (${header}, ${param}, etc.)
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |
Version|5.0.19 |Nightly Build
--- Additional Comments From [EMAIL PROTECTED] 2004-04-06 06:03 ---
Still fails with latest nightly build (4-4-2004)
Here's the exception report for the attached source:
type Exception report
message
description The server encountered an internal error () that prevented it from
fulfilling this request.
exception
org.apache.jasper.JasperException
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:316)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:277)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:223)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
root cause
java.lang.NullPointerException
org.apache.jsp.test.test8_005fheader_jsp._jspService(test8_005fheader_jsp.java:173)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:268)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:277)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:223)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC evolment
From Costin Manolache Sent: Tuesday, April 06, 2004 7:38 AM To: [EMAIL PROTECTED] Subject: Re: TC evolment That's probably why I tought let's integrate PHP was an April 1 joke :-). You were wrong. I thought that MS-Sun agreement was a April fools joke too :). If Mladen is serious about that - I would love to see a solution, hopefully one that can be reused for other systems as well. I'll do my best :) Again - I don't want to discourage Mladen, but to see if he's aware of the problems and if he has some good solution. Don't worry, I'm very stubborn. You'll have to try much harder to discourage me. I would like to see more on the design and tricks he intends to use, maybe we can all learn some stuff. You guys are be the first to know :). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with stress tested apps
Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TC Cluster: does SmartQueue fit into DeltaManager
Hi, I opened Bug 28161 last week. I found out yesterday, that the problem comes from using the SmartQueue together with DeltaManager and asynchronous replication (see Bug-Report for details). What are the plans now? If I knew, that a fix will take several days I might substitute the SmartQueue by an improvised FIFO to proceed with further tests on our application. Any comments are welcome, especially your opinion on the problem and on what to expect technically and with respect to time frame from a fix. Thank you for the important and very good work you all do on Tomcat. Sincerely Rainer Jung kippdata informationstechnologie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with stress tested apps
Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) at java.lang.Thread.run(Thread.java:534) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote RequestInfo.java
hgomez 2004/04/05 23:59:54
Modified:coyote/src/java/org/apache/coyote RequestInfo.java
Log:
Avoid NPE.
It appears at the end of some stress tests.
Revision ChangesPath
1.9 +4 -2
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java
Index: RequestInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- RequestInfo.java 24 Feb 2004 08:54:29 - 1.8
+++ RequestInfo.java 6 Apr 2004 06:59:54 - 1.9
@@ -49,8 +49,10 @@
this.global=global;
global.addRequestProcessor( this );
} else {
-this.global.removeRequestProcessor( this );
-this.global = null;
+ if (this.global != null) {
+ this.global.removeRequestProcessor( this );
+ this.global = null;
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote RequestInfo.java
hgomez 2004/04/06 00:01:08
Modified:coyote/src/java/org/apache/coyote RequestInfo.java
Log:
Tab policies
Revision ChangesPath
1.10 +2 -2
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java
Index: RequestInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- RequestInfo.java 6 Apr 2004 06:59:54 - 1.9
+++ RequestInfo.java 6 Apr 2004 07:01:08 - 1.10
@@ -50,8 +50,8 @@
global.addRequestProcessor( this );
} else {
if (this.global != null) {
- this.global.removeRequestProcessor( this );
- this.global = null;
+this.global.removeRequestProcessor( this );
+this.global = null;
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat build.properties.sample
hgomez 2004/04/06 00:29:48
Modified:.build.properties.sample
Log:
Correct jmxtools.jar for this example bp
Revision ChangesPath
1.5 +2 -2 jakarta-tomcat/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-tomcat/build.properties.sample,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.properties.sample 1 Jan 2004 23:20:46 - 1.4
+++ build.properties.sample 6 Apr 2004 07:29:48 - 1.5
@@ -48,7 +48,7 @@
jmx.home=../mx4j-1.1.1
jmx.lib=${jmx.home}/lib
jmx.jar=${jmx.lib}/mx4j-jmx.jar
-jmx-tools.jar=${jmx.lib}/mx4j-tools.jar
+jmxtools.jar=${jmx.lib}/mx4j-tools.jar
# - Commons Modeler, version 1.1 or later -
commons-modeler.home=../commons-modeler-1.1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat build.xml
hgomez 2004/04/06 00:12:31
Modified:.build.xml
Log:
We're now on 3.3.3-dev
Revision ChangesPath
1.204 +1 -1 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.203
retrieving revision 1.204
diff -u -r1.203 -r1.204
--- build.xml 3 Mar 2004 06:15:55 - 1.203
+++ build.xml 6 Apr 2004 07:12:31 - 1.204
@@ -25,7 +25,7 @@
property name=debug value=on/
!-- Version properties --
- property name=version value=3.3.2 /
+ property name=version value=3.3.3 /
property name=release value=Dev /
property name=version.release value=${version} ${release}/
property name=tomcat.name value=Tomcat ${version} /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28129] - Classloading for the security-constraint / Realm
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28129. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28129 Classloading for the security-constraint / Realm --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 08:32 --- I tested some more, and i'm somehow a little bit stupid. The problem is that i try to load the xml as URL (http://...) , which doesn't work because the URL is secured via the security-constraint and the Parser has no access to the xml, and tries to parse the login2.jsp, which in this case isn't a valid xml and he throws the Fatal Error. So its not a real bug, but now the question is, how can i give the Parser a role to get the access to the xml via URL ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28221] - scratchdir Can Break Virtual Hosts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28221. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28221 scratchdir Can Break Virtual Hosts [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 08:51 --- Yes, you indeed cannot set this globally. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28219] - Dolar sign in password of JNDI-Datasource disappears
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28219. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28219 Dolar sign in password of JNDI-Datasource disappears [EMAIL PROTECTED] changed: What|Removed |Added Component|Catalina|Webapps:Administration --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 09:08 --- At worst, this will only occur when you save your server.xml through the admin webapp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28196] - forEach throws with arrays (${header}, ${param}, etc.)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28196.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28196
forEach throws with arrays (${header}, ${param}, etc.)
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||INVALID
--- Additional Comments From [EMAIL PROTECTED] 2004-04-06 09:12 ---
This works for me. Please don't reopen this bug, and, more importantly, stop
using tag plugins.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteOutputStream.java CoyoteReader.java CoyoteRequest.java CoyoteWriter.java
Bill Barker wrote: I'm -0 on this. The classes modified are all internal to the Tomcat 5.x CoyoteConnector, so there is no good reason to make them public. The way that Coyote is designed, this should always be unnecessary. The way to build a new connector is to define a new ProtocolHandler that deals with the transport. I agree, but right now the access declarations were inconsistent. I know Jean-François used this for pretty advanced embedding, so being able to extend doesn't hurt. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28123] - ClientAbortException should default to the description of the wrapped exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28123. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28123 ClientAbortException should default to the description of the wrapped exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 09:20 --- I agree with Bill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28154] - setting of mappedfile in web.xml doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28154. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28154 setting of mappedfile in web.xml doesn't work [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 10:19 --- The changelog here: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/changelog.html says mappedFile Interestingly, our dev box which I've just upgraded to 5.0.19 does work as expected, merging template text with \n in the strings, whereas tomcat 5.0.14 on our live server doesn't... but the web.xml in our live server does mention mappedfile and release notes say mappedfile came in with v5.0.7. Anyway, I shall try and get our live server upgraded... thanks Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with stress tested apps
Henri Gomez wrote: Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) at java.lang.Thread.run(Thread.java:534) With the latest TC 3.3.3-dev, I didn't get the : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 And didn't see either the java.lang.NullPointerException in org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) Good for TC 5.0.22 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with stress tested apps
Henri Gomez wrote: Henri Gomez wrote: Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) at java.lang.Thread.run(Thread.java:534) With the latest TC 3.3.3-dev, I didn't get the : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 The logging has been adjusted. And didn't see either the java.lang.NullPointerException in org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) AFAIK, this was a race condition issue. Good for TC 5.0.22 ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
hey you
Norton AntiVirus gelöscht1.txt Description: plain/text - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC Cluster: does SmartQueue fit into DeltaManager
no, smart queue does not belong with the delta manager. it could never work that way, and never will :) Filip -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 1:35 AM To: [EMAIL PROTECTED] Subject: TC Cluster: does SmartQueue fit into DeltaManager Hi, I opened Bug 28161 last week. I found out yesterday, that the problem comes from using the SmartQueue together with DeltaManager and asynchronous replication (see Bug-Report for details). What are the plans now? If I knew, that a fix will take several days I might substitute the SmartQueue by an improvised FIFO to proceed with further tests on our application. Any comments are welcome, especially your opinion on the problem and on what to expect technically and with respect to time frame from a fix. Thank you for the important and very good work you all do on Tomcat. Sincerely Rainer Jung kippdata informationstechnologie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hi
attachment: ceyrisgppa.bmp- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteOutputStream.java CoyoteReader.java CoyoteRequest.java CoyoteWriter.java
Remy Maucherat wrote: Bill Barker wrote: I'm -0 on this. The classes modified are all internal to the Tomcat 5.x CoyoteConnector, so there is no good reason to make them public. The way that Coyote is designed, this should always be unnecessary. The way to build a new connector is to define a new ProtocolHandler that deals with the transport. I agree, but right now the access declarations were inconsistent. I know Jean-François used this for pretty advanced embedding, so being able to extend doesn't hurt. Exactly. I agree re-writting a Protocolhandler was the solution (and I did it), but I was still looking to extends CoyoteAdapter. As an example, if cookie are already parsed by the NSAPI, I don't want to call CoyoteAdapter.parseSessionId(..), but I still want to re-use the remaining of the class. -- Jeanfrancois Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28234] New: - uri: worker property does not exist any more
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28234 uri: worker property does not exist any more Summary: uri: worker property does not exist any more Product: Tomcat 5 Version: 5.0.19 Platform: Other URL: http://jakarta.apache.org/tomcat/tomcat-4.1- doc/jk2/jk2/configwebex.html OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The documentation still lists the 'worker' property in the examples. I guess this should be replaced by 'group'. Plus: Why does the URL read tomcat-4.1 BTW if I browse the 5.0 documentation? Very confusing. More comprehensive examples of how to use the context property would be nice. All in all documentation seems too fuzzy to me. It would definitely nice to have good documentation on all the parameters of the JK2 configuration. Cheers Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native build.xml
mmanders2004/04/06 09:40:57
Modified:jk/native build.xml
Log:
Updated build rev for NetWare modules.
Revision ChangesPath
1.40 +4 -4 jakarta-tomcat-connectors/jk/native/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/build.xml,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- build.xml 22 Jul 2003 21:45:38 - 1.39
+++ build.xml 6 Apr 2004 16:40:57 - 1.40
@@ -126,7 +126,7 @@
export fileName=${native.dir}/jni/jk_jnicb.exp if=netware /
linkOpt value=-desc quot;JNI Natives for Tomcatquot; if=netware /
linkOpt value=-screenname quot;System Consolequot; if=netware /
- linkOpt value=-nlmversion 1,2,5 if=netware /
+ linkOpt value=-nlmversion 1,2,6 if=netware /
linkOpt value=-threadname quot;JK_JNI Threadquot; if=netware /
linkOpt value=-stacksize 64000 if=netware /
@@ -220,7 +220,7 @@
import fileName=${apache2.home}/lib/aprlib.imp if=netware /
export symbol=jk_module if=netware /
linkOpt value=-desc quot;Apache 2.0 plugin for Tomcatquot; if=netware
/
- linkOpt value=-nlmversion 1,2,5 if=netware /
+ linkOpt value=-nlmversion 1,2,6 if=netware /
linkOpt value=-threadname quot;mod_jk Modulequot; if=netware /
linkOpt value=-stacksize 8192 if=netware /
linkOpt value=-l ${novelllibc.home}/imports if=netware /
@@ -302,7 +302,7 @@
export symbol=jk_module if=netware /
linkOpt value=-desc quot;Apache 1.3 plugin for Tomcatquot; if=netware
/
linkOpt value=-screenname quot;System Consolequot; if=netware /
- linkOpt value=-nlmversion 1,2,5 if=netware /
+ linkOpt value=-nlmversion 1,2,6 if=netware /
linkOpt value=-threadname quot;mod_jk Threadquot; if=netware /
linkOpt value=-stacksize 64000 if=netware /
@@ -436,7 +436,7 @@
export symbol=jk_service if=netware /
linkOpt value=-desc quot;Netscape Plugin for Tomcatquot; if=netware /
linkOpt value=-screenname quot;System Consolequot; if=netware /
- linkOpt value=-nlmversion 1,2,5 if=netware /
+ linkOpt value=-nlmversion 1,2,6 if=netware /
linkOpt value=-threadname quot;NSTomcat Threadquot; if=netware /
linkOpt value=-stacksize 64000 if=netware /
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28236] New: - org.apache.jasper.runtime.BodyContentImpl buffer is too small
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28236.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28236
org.apache.jasper.runtime.BodyContentImpl buffer is too small
Summary: org.apache.jasper.runtime.BodyContentImpl buffer is too
small
Product: Tomcat 5
Version: 5.0.19
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Well actually in reAllocBuff() method the policy is to incriment it by a
constant (512 bytes). In my case with a BIG select tag 99% of CPU is
used just to increment the buffer.
The suggestion is to use
***
len = Math.max(Constants.DEFAULT_TAG_BUFFER_SIZE, cb.length);
***
instead of
***
if (len Constants.DEFAULT_TAG_BUFFER_SIZE) {
len = Constants.DEFAULT_TAG_BUFFER_SIZE;
}
***
In my case (I'm using JSF RI 1.0) the change is from ~26 min to 2 sec.
Sincerely,
unknown
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=15278. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=15278 [PATCH] mod_jk2 for IIS, Bugfix corrupted data ] --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 17:20 --- Hi Mladen, That build seems to work for me; thanks for posting it! The systems I tested it with were: -w2k machines -IIS v5.xxx -Tomcat 4.1.29 -J2sdk 1.4.2_03 (and 1.4.2_01, I believe) Cheers, Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28147] - JasperException for jsp files that are symbolic links
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28147 JasperException for jsp files that are symbolic links [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 17:28 --- This will not be fixed. If you care, please submit a fix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
funkman 2004/04/06 10:58:59
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
Allow disable tag pooling for ant task (and command line option)
also detabbed
Revision ChangesPath
1.69 +97 -85
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -r1.68 -r1.69
--- JspC.java 17 Mar 2004 19:23:03 - 1.68
+++ JspC.java 6 Apr 2004 17:58:59 - 1.69
@@ -1,12 +1,12 @@
/*
* Copyright 1999,2004 The Apache Software Foundation.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -108,6 +108,7 @@
private static final String SWITCH_TRIM_SPACES = -trimSpaces;
private static final String SWITCH_CLASSPATH = -classpath;
private static final String SWITCH_DIE = -die;
+private static final String SWITCH_POOLING = -poolingEnabled;
private static final String SHOW_SUCCESS =-s;
private static final String LIST_ERRORS = -l;
private static final int NO_WEBXML = 0;
@@ -116,19 +117,20 @@
private static final int DEFAULT_DIE_LEVEL = 1;
private static final int NO_DIE_LEVEL = 0;
-private static final String[] insertBefore =
-{ /web-app, servlet-mapping, session-config,
+private static final String[] insertBefore =
+{ /web-app, servlet-mapping, session-config,
mime-mapping, welcome-file-list, error-page, taglib,
resource-env-ref, resource-ref, security-constraint,
- login-config, security-role, env-entry, ejb-ref,
+ login-config, security-role, env-entry, ejb-ref,
ejb-local-ref };
-private static int die;
+private static int die;
private String classPath = null;
private URLClassLoader loader = null;
private boolean trimSpaces = false;
private boolean xpoweredBy;
private boolean mappedFile = false;
+private boolean poolingEnabled = true;
private File scratchDir;
private String ieClassId = DEFAULT_IE_CLASS_ID;
private String targetPackage;
@@ -261,6 +263,13 @@
die = dieLevel;
} else if (tok.equals(SWITCH_HELP)) {
helpNeeded = true;
+} else if (tok.equals(SWITCH_POOLING)) {
+tok = nextArg();
+if (false.equals(tok)) {
+poolingEnabled = false;
+} else {
+poolingEnabled = true;
+}
} else {
if (tok.startsWith(-)) {
throw new JasperException(Unrecognized option: + tok +
@@ -296,7 +305,11 @@
}
public boolean isPoolingEnabled() {
-return true;
+return poolingEnabled;
+}
+
+public void setPoolingEnabled(boolean poolingEnabled) {
+this.poolingEnabled = poolingEnabled;
}
public boolean isXpoweredBy() {
@@ -312,19 +325,19 @@
}
public int getTagPoolSize() {
- return Constants.MAX_POOL_SIZE;
+return Constants.MAX_POOL_SIZE;
}
/**
* Are we supporting HTML mapped servlets?
*/
public boolean getMappedFile() {
- return mappedFile;
+return mappedFile;
}
// Off-line compiler, no need for security manager
public Object getProtectionDomain() {
- return null;
+return null;
}
public boolean getSendErrorToClient() {
@@ -366,14 +379,14 @@
* Is the generation of SMAP info for JSR45 debuggin suppressed?
*/
public boolean isSmapSuppressed() {
- return true;
+return true;
}
/**
* Should SMAP info for JSR45 debugging be dumped to a file?
*/
public boolean isSmapDumped() {
- return false;
+return false;
}
/**
@@ -413,7 +426,7 @@
}
public TldLocationsCache getTldLocationsCache() {
- return tldLocationsCache;
+return tldLocationsCache;
}
/**
@@ -423,14 +436,14 @@
* @return String The encoding
*/
public String getJavaEncoding() {
- return javaEncoding;
+return javaEncoding;
}
/**
* Sets
Re: Problems with stress tested apps
- Original Message - From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 5:08 AM Subject: Re: Problems with stress tested apps Henri Gomez wrote: Henri Gomez wrote: Hi to all, I've got problems with some highly stressed applications using jk or jk2 and tomcat 3.3.2 (same thing with TC 5.0.x). I see many errors like these in log : in TC 3.3.2 and 5.0.19 : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 in 5.0.19 I've got also : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest WARNING: Error registering request There is something weird in jtc, since the INFO: Unknown message 0 indicate that there is an invalid command on the AJP13 link. The problem appears with both jk and jk2, so I suspect the problem to be on the java side. I'm investigating the problem. While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the INFO: Unknown message 0 but got some : 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection GRAVE: Error, releasing connection java.lang.NullPointerException at org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:644) at java.lang.Thread.run(Thread.java:534) With the latest TC 3.3.3-dev, I didn't get the : Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 This is BZ #27881. With 3.3.2 (unless you JMX-register the CoyoteConnector yourself :) it doesn't do anything except fill up your log file when threads die. Of course, you can always swap in the JK jar from 5.0.21 if you don't want to see the message. And didn't see either the java.lang.NullPointerException in org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52) Good for TC 5.0.22 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding me
subscribe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Custom session tracking method?
Hi all,
Is there a way to implement custom session tracking at the container
level?
I'm trying to figure out how to implement a custom session tracking
method. I have a legacy client that interacts with a set of cgi scripts
and I'd like to port those scripts to servlets. I'm running into a
problem because the client passes session ids as a query parameter
named 'session-num' (e.g.: /update?session-num=TOKEN). The client does
not support cookies and there is no way to tell it use a JSESSIONID
encoded in the path.
I've followed the code as best as I can starting at
org.apache.coyote.tomcat5.CoyoteAdapter parses the JSESSIONID from the
request/cookies to where the org.apache.catalina.Manager fetches the
org.apache.catalina.Session and I don't see anyway to directly override
the session tracking behavior.
The best idea I currently have is to use a Valve and a custom Manager
and hope none of the Manager.{create,find}Session() methods are called
before my Valve can parse the request and stuff the session-num in a
ThreadLocal that Manager can use when returning a Session.
That feels ugly and fragile to me. Does anyone have a better solution?
Sandy McArthur
PGP.sig
Description: This is a digitally signed message part
DO NOT REPLY [Bug 28236] - org.apache.jasper.runtime.BodyContentImpl buffer is too small
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28236 org.apache.jasper.runtime.BodyContentImpl buffer is too small --- Additional Comments From [EMAIL PROTECTED] 2004-04-06 22:05 --- Anyway, why don't you suggest len = 2 * cb.length ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
Ok, I decided to modify the Http11Processor, since the SSL trick is kindof too hacky for my taste. It sets the attribute, and it's fine now. Another issue came up though with flushing the OutputStream - and this is something unrelated to the previous conversation. So in org.apache.coyote.http11.InternalOutputBuffer when endRequest() is called - on line 442 socketBuffer.flushBuffer() will in turn call realWriteBytes which does a write on the actual outputStream, but nothing will ever call flush() on the outputStream. This is not noticeable in case of the normal java.net.SocketOutputStream (it's unbuffered from what i can tell), but since I have overriden the outputstream and my class needs to be either flush()'ed or close()'ed, as a result my stuff is never sent back to the client, hanging the requests. I would think it's reasonable to expect a flush at some point on the OutputStream when ending the request, no? This lack of flushing in not present in the HttpConnector, in tomcat 4. thank you -anton On Fri, 2004-04-02 at 17:14, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, April 02, 2004 10:46 AM Subject: Re: Coyote's ServerSocketFactory problem First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having. Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. It's probably possible to do what you want without much, if any, modifying of Tomcat code. If you were to setup a full SSLImplementation to implement your socket factory, then you could have your code return the identity information in response to 'request.getAttribute(org.apache.coyote.request.X509Certificate)'. This should work because nothing in Tomcat outside of the SSLImplementation understands anything about SSL, so it won't really care that you aren't implementing real SSL. This method is a little hackish, but it has the advantage that you don't have to modify any of Tomcat's code to get it to work. The downside is that you have to implement a minimum of three classes, even if you can make most of the methods to be dummies. You'd also need to worry about the scheme getting set to https, but I could be talked into modifying that. Otherwise, you'd probably have to modify Http11Processor (about the only class that has access to both the Request and the Socket :) to set the attributes you want on the Request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.0.22 tag ?
I plan to tag 5.0.22 tomorrow. Any objections ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.22 tag ?
sounds good! Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 5:48 PM To: Tomcat Developers List Subject: 5.0.22 tag ? I plan to tag 5.0.22 tomorrow. Any objections ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime BodyContentImpl.java
remm2004/04/06 16:05:39
Modified:jasper2/src/share/org/apache/jasper/runtime
BodyContentImpl.java
Log:
- Bug 28236: when reallocating, make the buffer grow faster (512 bytes at a
time was not sufficient).
- Remove main method.
Revision ChangesPath
1.12 +2 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
Index: BodyContentImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- BodyContentImpl.java 17 Mar 2004 19:23:04 - 1.11
+++ BodyContentImpl.java 6 Apr 2004 23:05:39 - 1.12
@@ -547,15 +547,6 @@
}
}
-public static void main (String[] args) throws Exception {
- char[] buff = {'f','o','o','b','a','r','b','a','z','y'};
- BodyContentImpl bodyContent
- = new BodyContentImpl(new JspWriterImpl(null, 100, false));
- bodyContent.println (buff);
- System.out.println (bodyContent.getString ());
- bodyContent.writeOut (new PrintWriter (System.out));
-}
-
/**
* Sets the writer to which all output is written.
*/
@@ -595,8 +586,8 @@
return;
}
-if (len Constants.DEFAULT_TAG_BUFFER_SIZE) {
-len = Constants.DEFAULT_TAG_BUFFER_SIZE;
+if (len cb.length) {
+len = cb.length;
}
bufferSize = cb.length + len;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28236] - org.apache.jasper.runtime.BodyContentImpl buffer is too small
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28236. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28236 org.apache.jasper.runtime.BodyContentImpl buffer is too small [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Losing line numbers in stracktraces
Hello I have a problem reading stacktrace info when Tomcat throws an exception caused by a servlet or a class calld by a servlet I have my classes compiled into in the . WEB-INF/classes directory and (so far) I use no war or jar. When an exception is thrown the stacktrace does not show line numbers but Unknown source, which is not so handy. The classes are compiled correctly, in other circumstances the line numbers DO appear in stacktraces using the same classes. I am a relative newbie, so my questions are: 1. Do I need to configure the webapploader explicitly ? 2. Do I need some switch on de java statement when starting tomcat ? Kind regards, Hans
Re: Losing line numbers in stracktraces
Hans Verschoor wrote: I have a problem reading stacktrace info when Tomcat throws an exception caused by a servlet or a class calld by a servlet I have my classes compiled into in the . WEB-INF/classes directory and (so far) I use no war or jar. When an exception is thrown the stacktrace does not show line numbers but Unknown source, which is not so handy. The classes are compiled correctly, in other circumstances the line numbers DO appear in stacktraces using the same classes. I am a relative newbie, so my questions are: 1. Do I need to configure the webapploader explicitly ? 2. Do I need some switch on de java statement when starting tomcat ? Make sure you compile your classes with the -g flag to javac. Otherwise, line numbers will be optimized out. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java
luehe 2004/04/06 19:27:47
Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
Fixed problem where when replacing global JspServlet with
webapp-specific one, the wrapper for the global JspServlet (which had
already been stopped and marked unavailable) was still being
registered with JMX, because even though the wrapper had been removed
from the context's children, it was never removed from the wrappers
instance field.
Replaced all occurrences of wrappers with the result of
findChildren(), so that we don't need to maintain two lists of
wrapper children.
Revision ChangesPath
1.124 +18 -18
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
Index: StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
retrieving revision 1.123
retrieving revision 1.124
diff -u -r1.123 -r1.124
--- StandardContext.java 5 Apr 2004 22:40:07 - 1.123
+++ StandardContext.java 7 Apr 2004 02:27:47 - 1.124
@@ -569,8 +569,6 @@
*/
private transient DirContext webappResources = null;
-private ArrayList wrappers=new ArrayList();
-
private long startupTime;
private long startTime;
private long tldScanTime;
@@ -2315,7 +2313,6 @@
public Wrapper createWrapper() {
//log.info( Create wrapper );
Wrapper wrapper = new StandardWrapper();
-wrappers.add(wrapper);
synchronized (instanceListeners) {
for (int i = 0; i instanceListeners.length; i++) {
@@ -3105,9 +3102,10 @@
*/
public void removeChild(Container child) {
-if (!(child instanceof Wrapper))
+if (!(child instanceof Wrapper)) {
throw new IllegalArgumentException
(sm.getString(standardContext.notWrapper));
+}
super.removeChild(child);
@@ -4416,8 +4414,6 @@
// Reset application context
context = null;
-
-wrappers = new ArrayList();
}
/**
@@ -4523,8 +4519,6 @@
// Reset application context
context = null;
-wrappers = new ArrayList();
-
// This object will no longer be visible or used.
try {
resetContext();
@@ -5251,16 +5245,23 @@
}
-/** JSR77 servlets attribute
+/**
+ * JSR77 servlets attribute
*
* @return list of all servlets ( we know about )
*/
public String[] getServlets() {
-int size=wrappers.size();
-String result[]=new String[size];
-for( int i=0; i size; i++ ) {
-result[i]=((StandardWrapper)wrappers.get(i)).getObjectName();
+
+String[] result = null;
+
+Container[] children = findChildren();
+if (children != null) {
+result = new String[children.length];
+for( int i=0; i children.length; i++ ) {
+result[i] = ((StandardWrapper)children[i]).getObjectName();
+}
}
+
return result;
}
@@ -5325,10 +5326,9 @@
broadcaster.sendNotification(notification);
}
}
-for (Iterator it = wrappers.iterator(); it.hasNext() ; ) {
-StandardWrapper wrapper=(StandardWrapper)it.next();
-// XXX prevent duplicated registration
-wrapper.registerJMX( this );
+Container children[] = findChildren();
+for (int i=0; children!=null ichildren.length; i++) {
+((StandardWrapper)children[i]).registerJMX( this );
}
} catch (Exception ex) {
log.info(Error registering wrapper with jmx + this + +
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
luehe 2004/04/06 19:31:08
Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
Log:
JspServlet (global or webapp-specific) must always be preloaded,
because its instance is used during registerJMX (when registering the
JSP monitoring mbean)
Revision ChangesPath
1.41 +11 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
Index: StandardWrapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- StandardWrapper.java 20 Mar 2004 01:35:02 - 1.40
+++ StandardWrapper.java 7 Apr 2004 02:31:08 - 1.41
@@ -378,8 +378,16 @@
*/
public int getLoadOnStartup() {
-return (this.loadOnStartup);
-
+if (isJspServlet loadOnStartup 0) {
+/*
+ * JspServlet must always be preloaded, because its instance is
+ * used during registerJMX (when registering the JSP
+ * monitoring mbean)
+ */
+ return Integer.MAX_VALUE;
+} else {
+return (this.loadOnStartup);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28244] New: - XML Comment between jsp:attribute cause attribute after comment was ignored
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28244. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28244 XML Comment between jsp:attribute cause attribute after comment was ignored Summary: XML Comment between jsp:attribute cause attribute after comment was ignored Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The jspx code: ?xml version=1.0 ? fo:root xmlns:jsp=http://java.sun.com/JSP/Page; xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:block id=test font-weight=bold color=blue font-size=12pt jsp:element name=fo:inline jsp:attribute name=font-size9pt/jsp:attribute !-- -- jsp:attribute name=colorred/jsp:attribute jsp:attribute name=font-weightbold/jsp:attribute jsp:bodyHello World/jsp:body /jsp:element /fo:block /fo:root the output of resion 3.0.7 is: fo:inline font-size=9pt color=red font-weight=boldHello World/fo:inline and the tomcat 5.0.19 is: fo:inline font-size=9ptHello World/fo:inline Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
