svn commit: r371866 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Author: remm
Date: Tue Jan 24 00:52:54 2006
New Revision: 371866
URL: http://svn.apache.org/viewcvs?rev=371866view=rev
Log:
- Restore useless and inefficient code.
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java?rev=371866r1=371865r2=371866view=diff
==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
(original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Tue Jan 24 00:52:54 2006
@@ -599,6 +599,20 @@
throw new IllegalStateException
(sm.getString(coyoteResponse.getWriter.ise));
+/*
+ * If the response's character encoding has not been specified as
+ * described in codegetCharacterEncoding/code (i.e., the method
+ * just returns the default value codeISO-8859-1/code),
+ * codegetWriter/code updates it to codeISO-8859-1/code
+ * (with the effect that a subsequent call to getContentType() will
+ * include a charset=ISO-8859-1 component which will also be
+ * reflected in the Content-Type response header, thereby satisfying
+ * the Servlet spec requirement that containers must communicate the
+ * character encoding used for the servlet response's writer to the
+ * client).
+ */
+setCharacterEncoding(getCharacterEncoding());
+
usingWriter = true;
outputBuffer.checkConverter();
if (writer == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37356] - Tomcat does not invalidate sessions after session-timeout period has passed.
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=37356. 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=37356 --- Additional Comments From [EMAIL PROTECTED] 2006-01-24 12:59 --- I have found one problem about the accessCount. In some times, it will not decrease to 0 after one request. So the session manger will never invalidate it. The Tomcat version is 5.0.19. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38367] New: - Executing any Catalina Ant task results in an 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=38367.
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=38367
Summary: Executing any Catalina Ant task results in an exception
Product: Tomcat 5
Version: 5.5.14
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
which in turn breaks the build process.
Steps to Reproduce: Try executing any of the following targets where
target name=tomcat.application.deploy description=Install Web application
deploy url=${tomcat.management.url}
username=${tomcat.management.username}
password=${tomcat.management.password}
path=${web.context.path} war=${web.war.file}/
/target
target name=tomcat.application.reload description=Reload Web
application
reload url=${tomcat.management.url}
username=${tomcat.management.username}
password=${tomcat.management.password}
path=${web.context.path}/
/target
target name=tomcat.application.undeploy description=Remove Web
application
undeploy url=${tomcat.management.url}
username=${tomcat.management.username}
password=${tomcat.management.password}
path=${web.context.path}/
/target
target name=tomcat.application.start description=Start Tomcat
application.
start url=${tomcat.management.url}
username=${tomcat.management.username}
password=${tomcat.management.password}
path=${web.context.path}/
/target
target name=tomcat.application.stop description=Stop Tomcat
application.
stop url=${tomcat.management.url}
username=${tomcat.management.username}
password=${tomcat.management.password}
path=${web.context.path}/
/target
target name=tomcat.applications.list description=List Tomcat applications.
list url=${tomcat.management.url}
username=${tomcat.management.username}
password=${tomcat.management.password}/
/target
Actual Results: After executing the task ant throws an exception. Last part of
the description is the exact ant output (the lengthy html doc was removed from
the output)
Expected Results: There shouldn't be any exceptions thrown!
Build Date Platform: 5.5.15 (Here I could just select 5.5.14!)
Additional Information:
I imported the catalina-tasks.xml in my tomcat.xml that defines the above
targets.
Ant - version 1.6.5
JDK - version 1.5.0_06
IDE - occurs with both netbeans (5RC1) and intellij(5.0.2).
Likely Solution:
The ant tasks just call the urls.. which in turn yield a complete html page..
make sure that when the ant tasks call the urls the result is not an html
document but something suitable and concise.
A faulty run with ant -verbose(I snipped out the html document part of the
output):
Detected Java version: 1.5 in: D:\opt\Java\jdk1.5.0_06\jre
Detected OS: Windows XP
parsing buildfile
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-debugger-jpda-ant.jar!/org/netbeans/modules/debugger/jpda/ant/antlib.xml
with URI =
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-debugger-jpda-ant.jar!/org/netbeans/modules/debugger/jpda/ant/antlib.xml
parsing buildfile
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-debugger-jpda-ant.jar!/org/netbeans/modules/debugger/jpda/ant/antlib.xml
with URI =
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-debugger-jpda-ant.jar!/org/netbeans/modules/debugger/jpda/ant/antlib.xml
parsing buildfile
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-ant-browsetask.jar!/org/netbeans/modules/ant/browsetask/antlib.xml
with URI =
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-ant-browsetask.jar!/org/netbeans/modules/ant/browsetask/antlib.xml
parsing buildfile
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-ant-browsetask.jar!/org/netbeans/modules/ant/browsetask/antlib.xml
with URI =
jar:file:/D:/opt/netbeans/ide6/ant/nblib/org-netbeans-modules-ant-browsetask.jar!/org/netbeans/modules/ant/browsetask/antlib.xml
parsing buildfile
jar:file:/D:/opt/netbeans/profiler1/ant/nblib/org-netbeans-modules-profiler.jar!/org/netbeans/modules/profiler/antlib.xml
with URI =
jar:file:/D:/opt/netbeans/profiler1/ant/nblib/org-netbeans-modules-profiler.jar!/org/netbeans/modules/profiler/antlib.xml
parsing buildfile
jar:file:/D:/opt/netbeans/profiler1/ant/nblib/org-netbeans-modules-profiler.jar!/org/netbeans/modules/profiler/antlib.xml
with URI =
Re: Nightly builds broken
Hi Yoav, Yoav Shapira wrote: Hi, A user pointed out to me that our nightly builds appear to be broken. First I assumed it was due Gump unhappiness and I thought Mark T and Bill B fixed it over the past few days. But last night's builds still look whacky: http://cvs.apache.org/builds/jakarta-tomcat-5/nightly/. The binaries are 45 bytes in size and invalid, the sources are about 200MB in size (Tomcat 5.5.15 correct source distros are a little less than 6MB). Also as an aside, all the Gump files still call it jakarta-tomcat-* rather than apache-tomcat-* or just tomcat-*. I'm not a Gump expert, but I believe the Gump project file we want to update is (at least) http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-tomcat-catalina.xml. I've posted here a long time ago asking if we still want to have nightly or not, and got no response, So I stopped the script since it was still using CVS. Do we want nightly build? If yes, then I will fix the script and re-add it to the cron job. -- Jeanfrancois Thoughts? -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds broken
+1 to have nightly builds! Regards Peter Am 24.01.2006 um 16:52 schrieb Jeanfrancois Arcand: Hi Yoav, Yoav Shapira wrote: Hi, A user pointed out to me that our nightly builds appear to be broken. First I assumed it was due Gump unhappiness and I thought Mark T and Bill B fixed it over the past few days. But last night's builds still look whacky: http://cvs.apache.org/builds/jakarta-tomcat-5/ nightly/. The binaries are 45 bytes in size and invalid, the sources are about 200MB in size (Tomcat 5.5.15 correct source distros are a little less than 6MB). Also as an aside, all the Gump files still call it jakarta-tomcat-* rather than apache-tomcat-* or just tomcat-*. I'm not a Gump expert, but I believe the Gump project file we want to update is (at least) http://svn.apache.org/repos/asf/gump/metadata/project/jakarta- tomcat-catalina.xml. I've posted here a long time ago asking if we still want to have nightly or not, and got no response, So I stopped the script since it was still using CVS. Do we want nightly build? If yes, then I will fix the script and re-add it to the cron job. -- Jeanfrancois Thoughts? -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly builds broken
Hi, Mmm, I'm neutral on nightly builds. They can lead to more trouble than it's worth: - Users using a nightly build of unknown stability instead of an actual release, then asking for support - Extra load on infrastructure - Extra load on Gump people to keep the relevant scripts and Gumpy files up to date And for what? This user was the first request I've seen in a long long time for nightly builds, and he didn't even want the whole build, just the jsp examples webapp containing the XSS fix. So I don't think they're used that much, don't think they add much value. Anyone doing testing, be it individuals or organizations like JBoss, Covalent, Spikesource, whatever, isn't going to test, much less ship, off a nightly build. And if someone really wants a build at any time, it's easy (and documented) to build individually on the client side using our existing build file and its download target. Actually, maybe I'm closer to -1 than 0 on nightly builds ;) Yoav On 1/24/06, Peter Rossbach [EMAIL PROTECTED] wrote: +1 to have nightly builds! Regards Peter Am 24.01.2006 um 16:52 schrieb Jeanfrancois Arcand: Hi Yoav, Yoav Shapira wrote: Hi, A user pointed out to me that our nightly builds appear to be broken. First I assumed it was due Gump unhappiness and I thought Mark T and Bill B fixed it over the past few days. But last night's builds still look whacky: http://cvs.apache.org/builds/jakarta-tomcat-5/ nightly/. The binaries are 45 bytes in size and invalid, the sources are about 200MB in size (Tomcat 5.5.15 correct source distros are a little less than 6MB). Also as an aside, all the Gump files still call it jakarta-tomcat-* rather than apache-tomcat-* or just tomcat-*. I'm not a Gump expert, but I believe the Gump project file we want to update is (at least) http://svn.apache.org/repos/asf/gump/metadata/project/jakarta- tomcat-catalina.xml. I've posted here a long time ago asking if we still want to have nightly or not, and got no response, So I stopped the script since it was still using CVS. Do we want nightly build? If yes, then I will fix the script and re-add it to the cron job. -- Jeanfrancois Thoughts? -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build Problems
log.txt I'm ready to poke around the code and, following the build directions (and many variations!) at http://tomcat.apache.org/tomcat-5.5-doc/building.html, am still unable to get the code downloaded and compiled. I'm on an XP box behind a firewall. The verbose log is attached. Assistance greatly appreciated! David Detected Java version: 1.5 in: C:\Program Files\Java\jdk1.5.0_02\jre Detected OS: Windows XP parsing buildfile D:\tomcatsource\build.xml with URI = file:///D:/tomcatsource/build.xml Project base dir set to: D:\tomcatsource [property] Loading D:\Documents and Settings\dmarsh\build.properties [property] Loading D:\tomcatsource\build.properties [property] Unable to find property file: D:\tomcatsource\build.properties [property] Loading D:\tomcatsource\build.properties.default Override ignored for property version Build sequence for target(s) `build' is [check.source, get.source, build] Complete build sequence is [check.source, get.source, build, checkout, clean, ] check.source: [available] Unable to find dir build to set property source.exists get.source: Project base dir set to: D:\tomcatsource [antcall] calling target(s) [checkout] in build file D:\tomcatsource\build.xml parsing buildfile D:\tomcatsource\build.xml with URI = file:///D:/tomcatsource/build.xml Project base dir set to: D:\tomcatsource [property] Loading D:\Documents and Settings\dmarsh\build.properties Override ignored for property base.path Override ignored for property proxy.host Override ignored for property proxy.use Override ignored for property proxy.port [property] Loading D:\tomcatsource\build.properties [property] Unable to find property file: D:\tomcatsource\build.properties [property] Loading D:\tomcatsource\build.properties.default Override ignored for property commons-httpclient.home Override ignored for property commons-launcher.bin Override ignored for property commons-logging.jar Override ignored for property jmx-remote.jar Override ignored for property rhino.home Override ignored for property commons-launcher.jar Override ignored for property jdt.lib Override ignored for property commons-el.lib Override ignored for property jsse.lib Override ignored for property activation.lib Override ignored for property jdt.loc Override ignored for property commons-el.loc Override ignored for property activation.home Override ignored for property commons-el.home Override ignored for property jsp-api.jar Override ignored for property jsp-api.home Override ignored for property commons-modeler.jar Override ignored for property jmx.home Override ignored for property jdt.home Override ignored for property jta.lib Override ignored for property jmx-tools.jar Override ignored for property commons-fileupload.home Override ignored for property struts.lib Override ignored for property mail.jar Override ignored for property struts.loc Override ignored for property commons-logging.home Override ignored for property commons-digester.home Override ignored for property commons-collections.home Override ignored for property commons-dbcp.version Override ignored for property jta.home Override ignored for property servlet-api.home Override ignored for property commons-fileupload.jar Override ignored for property commons-beanutils.lib Override ignored for property commons-collections.lib Override ignored for property commons-launcher.bootstrap.class Override ignored for property nsis.installoptions.dll Override ignored for property servlet-api.lib Override ignored for property commons-beanutils.loc Override ignored for property commons-collections.loc Override ignored for property version Override ignored for property jcert.jar Override ignored for property commons-daemon.lib Override ignored for property compile.optimize Override ignored for property jnet.jar Override ignored for property commons-dbcp-src.loc Override ignored for property jdt.jar Override ignored for property commons-el.jar Override ignored for property commons-daemon.loc Override ignored for property puretls.lib Override ignored for property jsse.jar Override ignored for property activation.jar Override ignored for property struts.home Override ignored for property commons-httpclient.lib Override ignored for property jta.jar Override ignored for property commons-httpclient.loc Override ignored for property base-xml.loc Override ignored for property struts.jar Override ignored for property base-logging.loc Override ignored for property junit.lib Override ignored for property log4j.lib Override ignored for property junit.loc Override ignored for property commons-daemon.home Override ignored for property base-tomcat.loc Override ignored for property log4j.loc Override ignored for property version.major Override ignored for property xercesImpl.jar Override ignored for property xml-apis.jar Override ignored for property commons-pool.home Override ignored for property nsis.exe Override ignored for property commons-beanutils.jar Override ignored for property
Re: Build Problems
Hi David, in order to build tomcat from svn, you need svn installed and on the path. Thanks, Keith Marsh David W Maj AFIT/ENG wrote: java.io.IOException: CreateProcess: svn checkout http://svn.apache.org/repos/asf//tomcat/current/tc5.5.x D:\tomcatsource error=2 at java.lang.ProcessImpl.create(Native Method) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Build Problems
Sorry. Yeah, it's on the path. Relevant feedback: checkout: [echo] If the checkout fails, - todo - [exec] Current OS is Windows XP [exec] Executing 'svn' with arguments: [exec] 'checkout' [exec] 'http://svn.apache.org/repos/asf//tomcat/current/tc5.5.x' [exec] 'D:\tomcat.source' [exec] [exec] The ' characters around the executable and arguments are [exec] not part of the command. [exec] svn: PROPFIND request failed on '/repos/asf/tomcat/current/tc5.5.x' [exec] svn: PROPFIND of '/repos/asf/tomcat/current/tc5.5.x': 501 Not Implemented (http://svn.apache.org) [exec] Result: 1 [antcall] Exiting D:\tomcat.source\build.xml. Thanks. David -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 11:55 AM To: Tomcat Developers List Subject: Re: Build Problems Hi David, in order to build tomcat from svn, you need svn installed and on the path. Thanks, Keith Marsh David W Maj AFIT/ENG wrote: java.io.IOException: CreateProcess: svn checkout http://svn.apache.org/repos/asf//tomcat/current/tc5.5.x D:\tomcatsource error=2 at java.lang.ProcessImpl.create(Native Method) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 24, 2006 12:52 AM
To: Tomcat Developers List
Subject: Re: svn commit: r371765 -
/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catali
na/connector/Response.java
Bill Barker wrote:
Author: remm
Date: Mon Jan 23 17:13:19 2006
New Revision: 371765
URL: http://svn.apache.org/viewcvs?rev=371765view=rev
Log:
- Remove nonsensical systematic inclusion on ISO-8859-1
charset in the content type, which is noth
useless and inefficient.
-1
Sending the charset used by the Writer is very clearly
required by the
servlet spec.
Thanks, I expected no less coming from you :) I will revert my patch.
A couple questions for your enjoyment:
1) Is this relevant or irrelevant from the HTTP specification
perspective ?
It's relevant to the browser trying to display the code. If you've
configured your browser's default encoding to EUC-JP, without the charset
you'll see a big mess when you hit a latin-1 page ;-).
2) Does this mean we're running the following ultra efficient code (I
don't even know why I accepted this stuff back then. It must
have been
that this has been done gradually through many many commits) for each
request that uses a writer ?
Yup, that's what it means :). I'm sure you've played the blame-game by now,
and I'm not interested enough to do it myself. It looks like it's trying to
avoid computing the entire header value each time the characterEncoding
changes.
public String getContentType() {
String ret = contentType;
if (ret != null
characterEncoding != null
charsetSet) {
ret = ret + ;charset= + characterEncoding;
}
return ret;
}
Rémy
-
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]
RE: Nightly builds broken
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoav Shapira Sent: Tuesday, January 24, 2006 7:49 AM To: Tomcat-dev Subject: Nightly builds broken Hi, A user pointed out to me that our nightly builds appear to be broken. First I assumed it was due Gump unhappiness and I thought Mark T and Bill B fixed it over the past few days. But last night's builds still look whacky: http://cvs.apache.org/builds/jakarta-tomcat-5/nightly/. The binaries are 45 bytes in size and invalid, the sources are about 200MB in size (Tomcat 5.5.15 correct source distros are a little less than 6MB). Actually, Gump runs (or at least the one that nags) on vmgump.apache.org (http://vmgump.apache.org/gump/public/index.html). Also, Gump hasn't published the jars it builds for quite some time (to avoid licensing issues). Also Gump builds aren't true nightlies, since they build everything against the HEAD of everything else, not against the version specified in build.properties.default. Also as an aside, all the Gump files still call it jakarta-tomcat-* rather than apache-tomcat-* or just tomcat-*. I'm not a Gump expert, but I believe the Gump project file we want to update is (at least) http://svn.apache.org/repos/asf/gump/metadata/project/jakarta- tomcat-catalina.xml. Actually the closest to a nightly would be jakarta-tomcat-5.xml, but that one hasn't built in about 6 months (currently because of axis, before that xdoclet). The jakarta-tomcat-catalina one is only the 5.5 container part of the build. I was too lazy to change the gump project names on the svn move :). There are about seven jakarta-tomcat*.xml project files, and three jakarta-servlet-api*.xml files that would need to be moved. You'd also need to change the reference to the files in profile/gump.xml, and track down all of the other projects that depend on them (e.g. 67 for jakarta-servletapi-4) and change it there as well. All ASF committers have karma for the Gump metadata, so if anybody feels strongly about the names, knock yourself out :). Thoughts? -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - 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]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Bill Barker wrote: It's relevant to the browser trying to display the code. If you've configured your browser's default encoding to EUC-JP, without the charset you'll see a big mess when you hit a latin-1 page ;-). Obviously, this would only impact the case where ;charset=ISO-8859-1 would be forcefully added to the content-type header for no good reason when the user didn't specify any. This is the HTTP default encoding, and will not change the behavior from the user perspective. Yup, that's what it means :). I'm sure you've played the blame-game by now, and I'm not interested enough to do it myself. It looks like it's trying to avoid computing the entire header value each time the characterEncoding changes. This whole thing is a huge mess right now. Hopefully, it's doing what it should. You can also for example compare o.a.c.connector.Response.setContentType with o.a.coyote.Response.setContentType. I have to suppose substring and concatenation is a very cool activity. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Purpose of the SVN /bin directory?
Hi, It's an intermediate staging area for some compiled files. It's not part of the SVN repository, as you can see at http://svn.apache.org/viewcvs.cgi/tomcat/. It gets generated during the build and cleaned up as part of the clean target. Yoav On 1/24/06, Glen Mazza [EMAIL PROTECTED] wrote: Hello, I've downloaded Tomcat off of SVN but am unsure what the tomcat/bin/ directory indicates, the svn page[1] doesn't describe it. It appears to be a bunch of compiled .class files--may I ask what they're for, and why they are in SVN? Thanks, Glen [1] http://tomcat.apache.org/svn.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38373] - [PATCH] Patch to change to ASF logo on FAQ pages
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=38373. 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=38373 --- Additional Comments From [EMAIL PROTECTED] 2006-01-25 03:33 --- Created an attachment (id=17496) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17496action=view) Patch to switch from Jakarta to ASF logo on FAQ pages -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38376] New: - Body content stack may not be properly maintained in the faces of exceptions
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=38376.
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=38376
Summary: Body content stack may not be properly maintained in the
faces of exceptions
Product: Tomcat 5
Version: 5.5.14
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
The code that increments _jspx_push_body_count_XXX[0], which is the count of the
number of outstanding calls to _jspx_page_context.pushBody() within a try block,
is properly within the conditional that is true only if doStartTag() returns
EVAL_BODY_INCLUDE. The corresponding code that decrements the same variable,
however, is not within the corresponding conditional, although the call to
_jspx_page_context.popBody() is. The outstanding count may therefore be wrong,
and the code that pops these extra BodyContents in the finally block pops too
few. In the following Jasper-generated code snippet, note that
_jspx_push_body_count_rwc_dbTry_0[0]++ on the third line is conditional, but
_jspx_push_body_count_rwc_dbTry_0[0]-- on the last line is not.
Jasper-generated code snippet:
if (_jspx_eval_rwc_formPhase_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
out = _jspx_page_context.pushBody();
_jspx_push_body_count_rwc_dbTry_0[0]++;
_jspx_th_rwc_formPhase_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent)
out);
_jspx_th_rwc_formPhase_0.doInitBody();
}
do {
...
int evalDoAfterBody = _jspx_th_rwc_formPhase_0.doAfterBody();
if (evalDoAfterBody != javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
break;
} while (true);
if (_jspx_eval_rwc_formPhase_0 !=
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
out = _jspx_page_context.popBody();
_jspx_push_body_count_rwc_dbTry_0[0]--; // THIS SHOULD BE IN THE IF BLOCK!
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38376] - Body content stack may not be properly maintained in the faces of exceptions
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=38376. 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=38376 --- Additional Comments From [EMAIL PROTECTED] 2006-01-25 05:50 --- Created an attachment (id=17500) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17500action=view) Change to Generator.java -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Remy Maucherat [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bill Barker wrote: It's relevant to the browser trying to display the code. If you've configured your browser's default encoding to EUC-JP, without the charset you'll see a big mess when you hit a latin-1 page ;-). Obviously, this would only impact the case where ;charset=ISO-8859-1 would be forcefully added to the content-type header for no good reason when the user didn't specify any. This is the HTTP default encoding, and will not change the behavior from the user perspective. Yes, RFC 2616 does specify iso-latin-1 as the default for HTTP/1.1 clients. However, section 3.4.1 is also relevant for HTTP/1.0 clients (like, say, the TCK :). In any case, it doesn't matter since section 5.4 of the servlet spec says must. Complaints go to the expert group; here we just develop Tomcat. Yup, that's what it means :). I'm sure you've played the blame-game by now, and I'm not interested enough to do it myself. It looks like it's trying to avoid computing the entire header value each time the characterEncoding changes. This whole thing is a huge mess right now. Hopefully, it's doing what it should. You can also for example compare o.a.c.connector.Response.setContentType with o.a.coyote.Response.setContentType. I have to suppose substring and concatenation is a very cool activity. Yeah, the spec is a mess wrt characterEncoding. Complaints to the same place as above :). The problem is that we need to deal with such pathological cases as: response.setContentType(text/html; charset=EUC-JP); // Oops, I want French instead of Japanese response.setCharacterEncoding(iso-8859-1); Since you can change your mind (according to the spec) many times before you actually grab the Writer, I don't really see a way around substring and concatenation being cool :). Of course, I would love to be proven wrong :). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
