DO NOT REPLY [Bug 44620] infinit loop in nio connector code
https://issues.apache.org/bugzilla/show_bug.cgi?id=44620 --- Comment #5 from tangy <[EMAIL PROTECTED]> 2008-03-21 00:02:24 PST --- Sorry for that I do not express it clearly(We made some mistake in it). Since our application will cause the following problem: 2008-3-21 14:54:12 org.apache.catalina.connector.CoyoteAdapter service 严重: An exception or error occurred in the container during the request processing java.lang.ArrayIndexOutOfBoundsException: 8192 at org.apache.coyote.http11.InternalNioOutputBuffer.write(InternalNioOutputBuffer.java:734) at org.apache.coyote.http11.InternalNioOutputBuffer.write(InternalNioOutputBuffer.java:641) at org.apache.coyote.http11.InternalNioOutputBuffer.sendHeader(InternalNioOutputBuffer.java:507) at org.apache.coyote.http11.Http11NioProcessor.prepareResponse(Http11NioProcessor.java:1707) at org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1023) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:379) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273) at org.apache.catalina.connector.Response.finishResponse(Response.java:492) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:310) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:879) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:719) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2080) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) 2008-3-21 14:54:12 org.apache.coyote.http11.Http11NioProcessor endRequest 严重: Error finishing response java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.coyote.http11.InternalNioOutputBuffer.write(InternalNioOutputBuffer.java:703) at org.apache.coyote.http11.InternalNioOutputBuffer.sendStatus(InternalNioOutputBuffer.java:460) at org.apache.coyote.http11.Http11NioProcessor.prepareResponse(Http11NioProcessor.java:1696) at org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1023) at org.apache.coyote.Response.action(Response.java:181) at org.apache.coyote.http11.InternalNioOutputBuffer.endRequest(InternalNioOutputBuffer.java:382) at org.apache.coyote.http11.Http11NioProcessor.endRequest(Http11NioProcessor.java:977) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:913) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:719) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2080) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) we changed the server.xml and set maxHttpHeaderSize="1024" , and which cause dead loop and cost 100%CPU. the detailed stack trace is below(tomcat 6.0.16): Daemon Thread [catalina-exec-4] (Suspended) InternalNioOutputBuffer.flushBuffer() line: 768 InternalNioOutputBuffer.addToBB(byte[], int, int) line: 616 InternalNioOutputBuffer.commit() line: 608 Http11NioProcessor.action(ActionCode, Object) line: 1024 Response.action(ActionCode, Object) line: 183 Response.sendHeaders() line: 379 OutputBuffer.doFlush(boolean) line: 305 OutputBuffer.close() line: 273 Response.finishResponse() line: 492 CoyoteAdapter.service(Request, Response) line: 310 Http11NioProcessor.process(NioChannel) line: 879 Http11NioProtocol$Http11ConnectionHandler.process(NioChannel) line: 719 NioEndpoint$SocketProcessor.run() line: 2080 ThreadPoolExecutor$Worker.runTask(Runnable) line: 885 ThreadPoolExecutor$Worker.run() line: 907 Thread.run() line: 619 At last we also increased the socket.appWriteBufSize="10240" and solved the problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44620] infinit loop in nio connector code
https://issues.apache.org/bugzilla/show_bug.cgi?id=44620 --- Comment #6 from tangy <[EMAIL PROTECTED]> 2008-03-21 00:04:36 PST --- sorry for typed mistake: we changed the server.xml and set maxHttpHeaderSize="1024" , should be we changed the server.xml and set maxHttpHeaderSize="10240" , -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cookies are broken in 6.0.16?
Hi all,
This is a follow up to thread "Cookies are broken in 6.0.16?"
http://marc.info/?t=12025394451&r=2&w=2
Before submitting a bug report on the matter exposed below I
wanted to open a discussion with Tomcat developpers about it.
Summary of the above thread :
- Problem :
If a webapp is using an equal sign in the value of a cookie,
Tomcat alter the cookie value.
- Explanation :
For security reason a change has been introduced in 5.5.26 and
6.0.16 to cookie management regarding the equal sign.
- Solution suggested by Filip Hanik in the thread:
All applications should be modified to use cookie.setVersion(1)
if they want to use equal sign in their value.
Using version 1 cookie surrounds all cookies attributes
with quotes and leave the value intact.
First of all, I'd like to point out that breaking existing cookie
behavior and requiring applications to be updated in order to
work properly is probably not the best choice ...
Clients tend to think twice before upgrading their application
to a more recent version and it is not a process they want to
perform every day...
In our webapp, we use an equal sign in a cookie's value.
Even though all other application server we use (BEA Weblogic,
IBM WebSphere) do not have the above problem. I have decided
not to brag too much about this decision for Tomcat and I was
in the process of updating our CMS to use cookie version 1...
but...
... it does not work with IE 7.
Why ?
Because a path is specified in our cookie. And Tomcat also
surrounds the path with quotes, which is not accepted by IE 7
(probably other version of IE too, I have not tested yet).
Here is a simple test case.
Place this jsp in a directory "subdir" inside a ROOT webapp.
<%
Cookie cookie1 = new Cookie("Cookie1", "Hello World 1!");
Cookie cookie2 = new Cookie("Cookie2", "Hello World 2!");
cookie2.setVersion(1);
Cookie cookie3 = new Cookie("Cookie3", "Hello World 3!");
cookie3.setPath("/subdir");
Cookie cookie4 = new Cookie("Cookie4", "Hello World 4!");
cookie4.setPath("/subdir");
cookie4.setVersion(1);
response.addCookie(cookie1);
response.addCookie(cookie2);
response.addCookie(cookie3);
response.addCookie(cookie4);
%>
Here is the Tomcat response will output :
Set-Cookie: Cookie1="Hello World 1!"
Set-Cookie: Cookie2="Hello World 2!"; Version=1
Set-Cookie: Cookie3="Hello World 3!"; Path=/subdir
Set-Cookie: Cookie4="Hello World 4!"; Version=1; Path="/subdir"
==> IE 7 does not send back the cookie #4.
If using fiddler, we alter the response that way :
Set-Cookie: Cookie1="Hello World 1!"
Set-Cookie: Cookie2="Hello World 2!"; Version=1
Set-Cookie: Cookie3="Hello World 3!"; Path=/subdir
Set-Cookie: Cookie4="Hello World 4!"; Version=1; Path=/subdir
==> IE 7 accepts all the cookie
I can understand the security reasons behind the modification
requiring quotes around cookies' attribute value.
So my questions are :
- What could be done in Tomcat to fix this ?
- Is the security problem real if it is why do other
application server vendors do not have this behavior ?
- As it break older application and it is not compatible
with IE 7 in some circumstances. Do you really think this
modification should be kept that way ?
Thanks in advance for your replies!
Best regards,
Olivier Jaquemet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Thank you for your answer Mark. Accept my apologies for bothering you with already fixed issues. I had not found the appropriate discussions in the archive. Olivier Mark Thomas wrote: Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: renaming jar files
Costin Manolache wrote:
What's the current status of commons-logging versus juli/logging ? Do
we still need the dep ?
in 5.5 we still support commoons logging, in 6.0, no more unless you
build the adapter from the extras package
Speaking of deps - I'm completely confused by tomcat-dbcp.jar - it
seems to break the build ( 'download' ) with JDK1.6, yet I can't find
that's because DBCP implements interfaces, and only implements the
java.sql/javax.sql up to JDK 1.5.
any usage in the code - and just removing it doesn't seem to hurt in
any way.
it's being used, removing it would prolly upset some users, as the DBCP
is the core for the tomcat connection pooling.
Am I missing something - the jar name is referenced if few
places, and there is a class name in Constants. I assume some JDBC
connector stuff would not work so well unless someone install the
package.
Costin
On 3/20/08, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
when the commons-logging jar files got updated, they also got renamed,
we missed a few spots,
some files in bin and conf still reference the old name, like
catalina.policy
// These permissions apply to the commons-logging API
grant codeBase "file:${catalina.home}/bin/commons-logging-api.jar" {
permission java.security.AllPermission;
};
Filip
-
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]
DO NOT REPLY [Bug 44494] Requests greater than 8k being truncated.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44494 --- Comment #17 from Filip Hanik <[EMAIL PROTECTED]> 2008-03-21 08:48:11 PST --- (In reply to comment #15) > Remy and Filip, thank you for immediate checks. > > Yes, the logic is same in all of them. > > (In reply to comment #11, #12) > > I tested the patch on 5.5 and it didn't work, I will look deeper into it > > I also tested the trunk patch, and couldn't get it to work properly > > I'm sorry, I might have made a mistake in something. > I will check them more. > > (In reply to comment #14) > > if we are streaming a few megabytes of data, tomcat would have to cache all > > that data in order to support mark properly. > > If it says more in detail, > Tomcat would have to cache data only after the mark() method calling, and > Tomcat would have to cache characters up to only the size > that the application specified with the method. yes, only after mark has been called, but if you set a readAheadLimit of 10MB, one has to cache that. > > Of course, we can choose to support these methods or not to support. > I think it's wonderful if Tomcat can support that. yes, it's not a question about supporting or not supporting, it's where in the code you support that. with the bytechunk/charchunk the byte arrays referenced left and right, it makes it so much harder. I'll create a little POC to show how simpl it it is > And I'm believing that the implementation of Tomcat has enough possibility. > goes against the KISS principle :) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
One last question Mark... The tc6.6.x trunk has the patch and it works fine, but not yet the tc5.5.x. Is it planned for the next 5.5.x release ? Olivier Jaquemet wrote: Thank you for your answer Mark. Accept my apologies for bothering you with already fixed issues. I had not found the appropriate discussions in the archive. Olivier Mark Thomas wrote: Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - 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: Cookies are broken in 6.0.16?
even the 6.0.x needs one more patch in order to be backwards compatible Filip Olivier Jaquemet wrote: One last question Mark... The tc6.6.x trunk has the patch and it works fine, but not yet the tc5.5.x. Is it planned for the next 5.5.x release ? Olivier Jaquemet wrote: Thank you for your answer Mark. Accept my apologies for bothering you with already fixed issues. I had not found the appropriate discussions in the archive. Olivier Mark Thomas wrote: Olivier Jaquemet wrote: So my questions are : - What could be done in Tomcat to fix this ? This has been discussed extensively on the dev list and there is a patch proposed. See the archives for details. - Is the security problem real if it is why do other application server vendors do not have this behavior ? Yes the problem is real. It won't affect every installation or every application but it does affect some. As for the other app servers: don't know - haven't tested them. - As it break older application and it is not compatible with IE 7 in some circumstances. Do you really think this modification should be kept that way ? No. Again, see the discussion in the archives. Mark - 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: svn commit: r639046 - /tomcat/tc6.0.x/trunk/STATUS.txt
Remy Maucherat wrote:
On Wed, 2008-03-19 at 18:17 -0600, Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
On Wed, 2008-03-19 at 22:43 +, [EMAIL PROTECTED] wrote:
+1 : remm, markt
- -1 : fhanik - I tried this patch, and it doesn't work, it hangs. I also saw
the bug report, informing about further issues that are still valid
+ +1 : fhanik - I don't think we should support mark/reset, we can supply a
filter that does it at the app level by wrapping getReader with a reader that
bufferes
That's used by that stupid readLine feature, I didn't add it to have
fun :(
sure doesn't sound like fun :)
but given what a complicated impl that would end up being, I'd remove
the support for it all together and have a Filter that does it with
extreme simplicity just configured in the global web.xml file.
the benefits are many
1. we don't need to have that kind of code support in our buffers, since
it proves to be very complicated
2. users still get the support if wanted (one can of course turn it off)
3. the actual implementation of mark,reset and readLine becomes very easy
any thoughts on taking that approach?
Since a BufferedReader is provided, I would say it's better to support
mark/reset. If removing it anyway, readLine should be redone.
If I got this right, and correct me if I don't, This could have been so
much easier, instead of Tomcat's complex implementation of the buffered
reader.
basically, if Tomcat implemented was just java.io.Reader, no buffering,
no readline, no nothing, then the whole problem would have been solved
by this simple filter (and I believe this still will solve the problem,
even with todays code)
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest)request;
HttpServletRequestWrapper wrapper = new
HttpServletRequestWrapper(req) {
BufferedReader reader = null;
public BufferedReader getReader() throws IOException {
if (reader==null) {
BufferedReader bf = super.getReader();
reader = new BufferedReader(bf);
}
return reader;
}
};
chain.doFilter(req, response);
}
what this filter does, is it relies on the already implemented
BufferedReader, no need to reinvent the wheel.
The java.io.BufferedReader, already has this logic implemented, and it
works, so CoyoteReader, will only be treated as a java.io.Reader, and we
can bypass all the stuff in Tomcat's code base
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44494] Requests greater than 8k being truncated.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44494
--- Comment #18 from Filip Hanik <[EMAIL PROTECTED]> 2008-03-21 10:24:06 PST
---
I posted to the dev lists about this, basically, one can just take advantage of
java.io.BufferedReader to do the caching
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest)request;
HttpServletRequestWrapper wrapper = new HttpServletRequestWrapper(req)
{
BufferedReader reader = null;
public BufferedReader getReader() throws IOException {
if (reader==null) {
BufferedReader bf = super.getReader();
reader = new BufferedReader(bf);
}
return reader;
}
};
chain.doFilter(req, response);
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r639046 - /tomcat/tc6.0.x/trunk/STATUS.txt
On Fri, 2008-03-21 at 11:25 -0600, Filip Hanik - Dev Lists wrote: > what this filter does, is it relies on the already implemented > BufferedReader, no need to reinvent the wheel. > The java.io.BufferedReader, already has this logic implemented, and it > works, so CoyoteReader, will only be treated as a java.io.Reader, and we > can bypass all the stuff in Tomcat's code base Maybe this piece of code is hopelessly broken and should be removed. If it's not, I think some effort should be made towards improving it [as well as improving the character conversion code], as double buffering is not something nice and a BufferedReader is a relatively expensive object. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 44494] Requests greater than 8k being truncated.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44494 Remy Maucherat <[EMAIL PROTECTED]> changed: What|Removed |Added Status|ASSIGNED|NEEDINFO --- Comment #19 from Remy Maucherat <[EMAIL PROTECTED]> 2008-03-21 11:59:45 PST --- Did you really need to get three emails posted on the mailing list to express this idea ? Personally, I would be interested to know exactly which cases are not working at the moment after applying: Index: java/org/apache/catalina/connector/InputBuffer.java === --- java/org/apache/catalina/connector/InputBuffer.java (revision 633279) +++ java/org/apache/catalina/connector/InputBuffer.java (working copy) @@ -355,7 +355,7 @@ } state = CHAR_STATE; -conv.convert(bb, cb, len); +conv.convert(bb, cb, bb.getLength()); bb.setOffset(bb.getEnd()); return cb.getLength(); This includes no mark usage and with marks (which can probably be tested using readLine).Could I get some test cases ? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r639771 - /tomcat/trunk/conf/web.xml
Author: markt Date: Fri Mar 21 12:29:35 2008 New Revision: 639771 URL: http://svn.apache.org/viewvc?rev=639771&view=rev Log: No longer need to rename jars for CGI or SSI. Modified: tomcat/trunk/conf/web.xml Modified: tomcat/trunk/conf/web.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/conf/web.xml?rev=639771&r1=639770&r2=639771&view=diff == --- tomcat/trunk/conf/web.xml (original) +++ tomcat/trunk/conf/web.xml Fri Mar 21 12:29:35 2008 @@ -277,11 +277,6 @@ - - - - - - - - - - - - - -
svn commit: r639772 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Fri Mar 21 12:32:03 2008 New Revision: 639772 URL: http://svn.apache.org/viewvc?rev=639772&view=rev Log: Propose another patch Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=639772&r1=639771&r2=639772&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Mar 21 12:32:03 2008 @@ -121,3 +121,8 @@ http://svn.apache.org/viewvc?rev=639198&view=rev +1: markt -1: + +* Update comments re JAR renaming in web.xml + http://svn.apache.org/viewvc?rev=639771&view=rev + +1: + -1: \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r639046 - /tomcat/tc6.0.x/trunk/STATUS.txt
Remy Maucherat wrote: On Fri, 2008-03-21 at 11:25 -0600, Filip Hanik - Dev Lists wrote: what this filter does, is it relies on the already implemented BufferedReader, no need to reinvent the wheel. The java.io.BufferedReader, already has this logic implemented, and it works, so CoyoteReader, will only be treated as a java.io.Reader, and we can bypass all the stuff in Tomcat's code base Maybe this piece of code is hopelessly broken and should be removed. If it's not, I think some effort should be made towards improving it [as well as improving the character conversion code], as double buffering is not something nice and a BufferedReader is a relatively expensive object. I'd prefer to move forward with just the truncation fix so that we can move towards a release. Any other efforts can be postponed at this time. If the mark/reset bug in fact exists, there is an easy work around, and that is to use java.io.BufferedReader. whether the code is hopelessly broken or not, I don't have enough info to comment on. But I do think the code is too fragile to be mucked with in our 6.0.x branch, that can be done in trunk or sandbox. It's better for us to get a release out that takes care of the regressions that are in the releases we have now. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r639046 - /tomcat/tc6.0.x/trunk/STATUS.txt
On Fri, 2008-03-21 at 14:29 -0600, Filip Hanik - Dev Lists wrote: > I'd prefer to move forward with just the truncation fix so that we can > move towards a release. > > Any other efforts can be postponed at this time. If the mark/reset bug > in fact exists, there is an easy work around, and that is to use > java.io.BufferedReader. > > whether the code is hopelessly broken or not, I don't have enough info > to comment on. But I do think the code is too fragile to be mucked with > in our 6.0.x branch, that can be done in trunk or sandbox. > > It's better for us to get a release out that takes care of the > regressions that are in the releases we have now. This code has been used for a very long time. Where is the regression ? (actually, where is the bug ? feel free to post test cases to bug 44494) Personally, I am in no hurry to proceed with a release. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r639842 - /tomcat/trunk/webapps/docs/jndi-datasource-examples-howto.xml
Author: markt Date: Fri Mar 21 14:08:36 2008 New Revision: 639842 URL: http://svn.apache.org/viewvc?rev=639842&view=rev Log: maxActive setting for unlimited changed in commons-pool > 1.2 Modified: tomcat/trunk/webapps/docs/jndi-datasource-examples-howto.xml Modified: tomcat/trunk/webapps/docs/jndi-datasource-examples-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/jndi-datasource-examples-howto.xml?rev=639842&r1=639841&r2=639842&view=diff == --- tomcat/trunk/webapps/docs/jndi-datasource-examples-howto.xml (original) +++ tomcat/trunk/webapps/docs/jndi-datasource-examples-howto.xml Fri Mar 21 14:08:36 2008 @@ -219,7 +219,7 @@