tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: Bug in B2C converter WAS: svn commit: r568307 - /tomcat/trunk/java/org/apache/tomcat/util/buf/
Date Tue, 04 Mar 2008 01:34:25 GMT
On 3/3/08, Remy Maucherat <> wrote:
> On Mon, 2008-03-03 at 15:58 -0700, Filip Hanik - Dev Lists wrote:
> > Remy Maucherat wrote:
> > > 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.
> I am not really interested in participating. Besides some possible
> simple cleanup, CharChunk is actually too simple rather than too complex
> (ByteChunk is just fine, and doesn't need additional features): to
> improve, it would need to get mark capabilities and (unfortunately) get
> a readLine (it's even more problematic to implement it outside the
> class). I am pretty sure using the NIO buffers will be proposed for some
> reason, which are horrible to use as far as I am concerned.

I think the byte->char conversion should be cleaned, the InputStream hack
needed 9 years ago because regular conversion sucked and we couldn't use
convertors directly. I've seen quite a few other projects doing the
themself at least for UTF8 and 8859-1.
Regarding using NIO buffers - I agree with Remy,  the flip()s are horrible,
I think
there is a version in sandbox that replaces byte[] with the ByteBuffers, and
it doesn't
seem to be worth it.
However I think it would be just great to start making a distinction between
'buffer' and
'pointer to a buffer' - IMO that's the main cause of complexity. And maybe
'implements CharSequence, Appendable' to make the coyote classes more
friendly for
direct use.

> for 6.0.x and 5.5.x, I'd rather keep the fixes to the actual bug fix to
> > maintain stability
> There's no way this sort of work could be good for these branches.

Since I'm quite out of sync - what is the current 'dev branch' and is there
'some API changes allowed' release planned ?

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message