Remy Maucherat wrote:
On Mon, 2008-03-03 at 21:13 +0000, Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
Remy Maucherat wrote:
On Thu, 2008-02-28 at 01:36 +0100, Remy Maucherat wrote:
Index: java/org/apache/catalina/connector/InputBuffer.java
===================================================================
---java/org/apache/catalina/connector/InputBuffer.java
(revision
630535)
+++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 seems to work for me. It should be equivalent to the value
returned
by the available method, since the value passed is the same (it is
the
amount of bytes which have been read).
Just to be clear, do you mean that the above patch
http://issues.apache.org/bugzilla/show_bug.cgi?id=44494 ?
that's correct
Filip
First off - sorry it has taken me a few days to reply.
Secondly, I still haven't had enough time to look at this in detail so
my
reasoning may be way off base. It it is, I apologise - feel free to
correct
me with or without flames.
Looking through the InputBuffer code, realReadBytes(), realReadChars()
and
realWriteChars() all ignore the parameters passed in with the
exception of
len in realReadChars() which the patch above changes so it too is
ignored.
It appears to me that all of these methods need to be modified not to
take
any parameters since they all operate on the internal buffers rather
than
the ones passed to them (a job for another day). On this basis, the
patch
above patch strikes me as the right way forward rather than the one
currently applied to trunk.
This problem is a small detail. Much more should be done if you want to
do a refactoring: both the mark functionality and readLine need to have
direct access to the buffer to be able to be coded in a sane way (and be
more efficient too).
yes, so the question is for 6.0.x and 5.5.x, do we wanna proceed down
the refactor route?
I was against it in the beginning for the fear of regression. I
personally think the whole bytechunk/charchunk thing is very complex,
and can be done easier, but that is something I would play around in
sandbox, and eventually bring into trunk if it was working.
for 6.0.x and 5.5.x, I'd rather keep the fixes to the actual bug fix to
maintain stability
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
