And Craig thought it was a strange world when he contributed to j-t-c. ;-)
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 15, 2002 11:47 PM
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/buf
ByteChunk.j
remm02/03/15 23:47:33
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
- Port indexOf patch to 3.3. Feel free to -1.
Revision ChangesPath
1.11 +7 -7
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
Index: ByteChunk.j
billbarker02/03/15 23:29:15
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
CharChunk.java
Log:
Porting fixes from j-t-c.
Revision ChangesPath
1.10 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChunk.java
keith 02/02/05 14:06:18
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
CharChunk.java
Log:
indexOf should return an index relative to the internal
starting point of the string rather than the beginning
of the array. ByteChunk.indexOf is u
nacho 01/06/03 13:16:46
Modified:src/share/org/apache/tomcat/core OutputBuffer.java
src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
* Fix for ob.getByteOff hack...and reverting previous fix..
* Use getStart where needed on bb intead of getOffset, a bit cl
> I reviewed it, and your are right for equals..but not for
> append..append
> is suppoused to use the end of the buffer not the start..so in append
> getOffset is suppoused to return end not the start...
>
This is not true...append needs getStart too...finally i will make this
changes:
1) use
"Ignacio J. Ortega" wrote:
>
> > perhaps i'm missing something, but it looks like the offset
> > returned by
> > getOffset() should be the offset into the byte array contained in
> > ByteChunk, which would be the start position in this case, rather than
> > the end position.
> >
>
> From the poi
> perhaps i'm missing something, but it looks like the offset
> returned by
> getOffset() should be the offset into the byte array contained in
> ByteChunk, which would be the start position in this case, rather than
> the end position.
>
>From the point of view of the o.a.t.m.s.ajp13, now getO
i was looking at the diffs here because i was going to propagate this
change to jakarta-tomcat-connectors, but i'm no sure i understand this:
>public int getOffset() {
> - return getStart();
> + return getEnd();
>}
perhaps i'm missing something, but it looks like the
nacho 01/06/02 14:53:46
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
Latest encoding fixes left some problems in the way.
Fixing a hack is a hazardous task..
Revision ChangesPath
1.5 +11 -10
jakarta-tomcat/src/share/org/apache/tomcat/ut
costin 01/05/26 10:17:02
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
CharChunk.java
Log:
Merged the resizable and flush-able buffer code from OutputBuffer.
Now the CharChunk and ByteChunk can be used as general-purpose buffers
( inste
costin 01/03/10 10:18:43
Modified:src/share/org/apache/tomcat/util/buf ByteChunk.java
Log:
First attempt to fix the UTF decoding bug.
This doesn't change the behavior - what worked before should work the
same ( i.e. bytes<0x80 ). For chars > 0x80 ( that didn't worked with
12 matches
Mail list logo
