DefaultServlet and getOutputStream() / getWriter()
Hi
I am reviewing the source code of the DefaultServlet.
I do not understand the following:
// slightly modified from source of serveResource.
ServletOutputStream ostream = null;
PrintWriter writer = null;
try {
ostream = response.getOutputStream();
} catch (IllegalStateException e) {
if ( contentType == null || contentType.startsWith( text ) )
writer = response.getWriter();
else
throw e;
}
}
Why would getOutputStream() fail?
And if that fails, why would getWriter() succeed?
Text data is also binary data, right?
I would understand that the other way around...
Regards,
Steffen
smime.p7s
Description: S/MIME cryptographic signature
Re: DefaultServlet and getOutputStream() / getWriter()
Responder, The email address you have contacted is no longer active. Please use your companys user log-in to www.apparelmagic.com/support to contact the ApparelMagic Support Department. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DefaultServlet and getOutputStream() / getWriter()
Steffen Heil wrote:
Hi
I am reviewing the source code of the DefaultServlet.
I do not understand the following:
// slightly modified from source of serveResource.
ServletOutputStream ostream = null;
PrintWriter writer = null;
try {
ostream = response.getOutputStream();
} catch (IllegalStateException e) {
if ( contentType == null || contentType.startsWith( text ) )
writer = response.getWriter();
else
throw e;
}
}
Why would getOutputStream() fail?
And if that fails, why would getWriter() succeed?
Text data is also binary data, right?
I would understand that the other way around...
That's definitely why I am not interested by code cleanups done by folks
who might not know all the small tricks: the risk of breaking stuff is
far greater than the gain.
For this particular case, you should look into the API javadocs.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: DefaultServlet and getOutputStream() / getWriter()
Responder, The email address you have contacted is no longer active. Please use your companys user log-in to www.apparelmagic.com/support to contact the ApparelMagic Support Department. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
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=31201. 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=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 09:29 --- 1. Converting HTML files into JSPs has following problems. - Since the JSP compile is needed, a performance may become a problem. - HTML files must be included correctly in JSP spec. I think requiring converting HTML into JSP means not fulfilling specification. 2.file.encoding option does not operate depending on the version of JVM. 1.1 OK 1.2 NG 1.3 - 1.4.1 OK 1.4.2 NG file.encoding is determined by default locale at the time of JVM execution. I recommend you to see the following page. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4163515 3. The best solution for including HTML files of multiple encodings is changing the JSP spec. First of all, a browser cannot display if multiple encodings are contained in 1 page. In this case, in a HTML file, you should use comprehensive encodings, such as UTF8. However, do you want to use UTF8 as default locale? This patch can separate encodings of default locale and web app. This patch extends options without any undesireble effects. Other options are still effective even if this patch is accepted. reagrds, Takayuki Kaneko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: DefaultServlet and getOutputStream() / getWriter()
Hi That's definitely why I am not interested by code cleanups done by folks who might not know all the small tricks: the risk of breaking stuff is far greater than the gain. Why are you soo hostile? I am just trying to get into the code and if I understand it, I will propably start to contribute something. But I need to start somewhere and I cannot know all the small tricks from beginning. THAT IS WHY I AM ASKING! I did not say remove that shit, nor did I say this is stupid. I just asked why it is done that way. Additionally, every change I suggested (on tomcat-user) was definitly not changing any behaviour, but maybe improving performance. So I need to give that back to the authors. Things that are not self-evident should be documented in code. There is nothing. And again, please see, that this is no allegation. But someone will know it and it is not in the code, so you should accept questions. You told me: ... submit more significant patches ... How should I, if I cannot even get information about easy things? For this particular case, you should look into the API javadocs. That's what I have done for some hours. Returns a ServletOutputStream suitable for writing binary data in the response. The servlet container does not encode the binary data. java.lang.IllegalStateException - if the getWriter method has been called on this response java.io.IOException - if an input or output exception occurred If I believe that javadocs, THERE IS NO REASON to do what the code does, sind getWriter is never called before getOutputStream, so there will never be the IllegalStateException and half of the code is obsolete. That is exactly the reason I am asking. Regards, Steffen smime.p7s Description: S/MIME cryptographic signature
Re: AW: DefaultServlet and getOutputStream() / getWriter()
Steffen, My understanding (and I might be wrong here, so someone please correct me if I am) is that once you've called getWriter(), you can't call getOutputStream() on the same request. The reason is primarily so that you have to use the same char encoding etc on included servlets as in the including servlet. Calling getOutputStream after getWriter results in an exception being thrown in Tomcat, hence the try/catch. Rick Knowles PS And for the record, I thought Remy's response was pretty harsh too. Steffen Heil wrote: Hi That's definitely why I am not interested by code cleanups done by folks who might not know all the small tricks: the risk of breaking stuff is far greater than the gain. Why are you soo hostile? I am just trying to get into the code and if I understand it, I will propably start to contribute something. But I need to start somewhere and I cannot know all the small tricks from beginning. THAT IS WHY I AM ASKING! I did not say remove that shit, nor did I say this is stupid. I just asked why it is done that way. Additionally, every change I suggested (on tomcat-user) was definitly not changing any behaviour, but maybe improving performance. So I need to give that back to the authors. Things that are not self-evident should be documented in code. There is nothing. And again, please see, that this is no allegation. But someone will know it and it is not in the code, so you should accept questions. You told me: ... submit more significant patches ... How should I, if I cannot even get information about easy things? For this particular case, you should look into the API javadocs. That's what I have done for some hours. Returns a ServletOutputStream suitable for writing binary data in the response. The servlet container does not encode the binary data. java.lang.IllegalStateException - if the getWriter method has been called on this response java.io.IOException - if an input or output exception occurred If I believe that javadocs, THERE IS NO REASON to do what the code does, sind getWriter is never called before getOutputStream, so there will never be the IllegalStateException and half of the code is obsolete. That is exactly the reason I am asking. Regards, Steffen -- Servlet v2.4 container in a single 140KB jar file ? Try Winstone (http://winstone.sf.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCKs for 4.1.31
Amy Roh wrote: Hey Keith, Hey Amy, would you mind running the TCKs against the 4.1.31 rc? http://apache.org/~keith/rc2/ How does one go about obtaining these tests? I only have the TCKs for the latest specs Servlet 2.4/JSP2.0 so it won't be compatible with Tomcat 4.1. I believe Apache has contacts that have access to the TCKs. I'll see if I can get the previous TCks and Apache contacts' names. I think we were using Watchdog for testing older Tomcat releases. The TCK was then run separately, but I don't think it was that different from Watchdog, so I never saw any results of that being posted. I don't really remember ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
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=31201. 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=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 11:19 --- 1. If performance is an issue, pre-compile your JSPs. If you can quote the part of the spec tomcat isn't following and the patch addresses this issue I'll commit it. However, having read the spec, and the errata, I believe tomcat is spec compliant. 2. I wasn't aware of this. Thanks for pointing this out. This is clearly not an option. 3. I think you mis-understood me. I was not trying to address one file with multiple encodings. My point is that your patch assumes (as does the current tomcat code) that ALL static files for all webapps will have the same encoding. Is this sufficient to address your i18n issues? Is it not possible to have one webapp with html files using one encoding and one webapp with thml files using a different one? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per session
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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 15:26 --- Created an attachment (id=13003) First improvement of DeltaRequest.java (not thread safe yet, but without exceptions) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31328] - DeltaRequest unable to handle two concurrent requests per session
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=31328. 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=31328 DeltaRequest unable to handle two concurrent requests per session --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 15:31 --- I've just added an attachment of DeltaRequest.java I now use for my production tomcat 5.0.27. The synchronized-statements avoid Exceptions on the sending side (like the NoSuchElementException I described) and on the receiving side (like EOFException that Rainer described). But it is not yet thread safe to solve the other problem with the writeExternal() / reset() that should be atomic. So it's still work in progress, but feel free to comment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31201] - Encoding bug when using jsp:include ... action
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=31201. 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=31201 Encoding bug when using jsp:include ... action --- Additional Comments From [EMAIL PROTECTED] 2004-10-09 16:43 --- 1.pre-compile is a good solution, but the sequence of replacing is complicate without stopping the web app while Tomcat is running. In a HTML file, I just need to replace it. It is much simple. I think your saying is not compliant the spec. If converting HTML into JSP is required, then HTML files can not be included. 3.My point is that it will be not necessary to consider the different static file encodings within the same web app. As having stated above, the problem of displaying still remains, there is no solution for a such web app in the present JSP specification. And there is no solution for even one static file encoding under present Tomcat. Takayuki Kaneko - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
making building releases easier?
Is it possible to make building tomcat official releases easier. Building from the cvs head is cake, but building 4.1.30 is a 27 step process. I basically wanted to change line 533 of PageContextImpl because I believe there is a bug there(t is not reported at all to the user so the real root cause is still hidden from the users). There have been 20 posts around an issue with struts which I really believe is a possible issue with struts but some minor changes to tomcat would probably make it extremely clear what the problem is. thanks for any info on this...ps. I may have some time to do this work which means I would have to figure out the 27 step process so I could make it more like 3-4 steps. thanks, dean
