commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [codec] regression in 1.4
Date Wed, 02 Dec 2009 01:18:03 GMT
On 02/12/2009, Julius Davies <juliusdavies@gmail.com> wrote:
> Hi,
>
>  Any opinions at all out there regarding this?
>
> https://issues.apache.org/jira/browse/CODEC-89
>
>
> Mat Booth, the Fedora commons-codec maintainer, left a message today
>  on CODEC-89:
>  ---
>  [...]
>  It definitely feels like a regression to me – I'm tempted to apply
>  this patch to the commons-codec distributed by Fedora Linux (I am the
>  maintainer there).
>  ---
>
>
>  Gary Gregory posted this on CODEC-89 a week ago:
>  ---
>  If you want, you can post to the dev list to ask for the community's
>  feedback. It would be good to see what other people think.
>  ---
>
>  And that's why I wrote the original email.  So, like I said up above:
>
>  Any opinions at all out there regarding this?
>
>

Whatever happens, someone is going to be unhappy.

But on the whole, I agree that if the behaviour was mistakenly changed
between 1.3 and 1.4 then it should be reverted, and release 1.4
deprecated (if such is possible).


>
>
>  yours,
>
>
>  Julius
>
>
>
>  On Mon, Nov 23, 2009 at 12:24 PM, Julius Davies <juliusdavies@gmail.com> wrote:
>  > Hi, Commons Developers,
>  >
>  >
>  > There's a minor regression in Codec-1.4 that causes two extra white
>  > space characters to appear at the very end of the Base64 output when
>  > using the instance encode() method instead of the static one:
>  >
>  > https://issues.apache.org/jira/browse/CODEC-89
>  >
>  > This seems to be causing some interop problems for clients.  For
>  > example, one person on the commons-user mailing list appeared to be
>  > comparing output of Codec-1.4 against values stored in a database
>  > using Codec-1.3 - so obviously they are having problems!  They can
>  > workaround using trim() or switching to the static method, but they
>  > don't expect to have this problem.
>  >
>  > I suspect this problem is also behind the issues these people
>  > experienced, but that's all I could find after about 15 minutes
>  > playing with the google.
>  >
>  > http://alphawit.com/blog/2009/oct/12/amazon-vs-apache-my-base64-better-your-base64/
>  >
>  > http://code.google.com/p/oauth-signpost/issues/detail?id=18
>  >
>  >
>  >
>  > Should we release a 1.4.1 and fix the API to bring it back inline with
>  > Commons-Codec-1.3?  (If yes, then the sooner the better I think!)  Or
>  > should we leave the API as it is?
>  >
>  > Sorry I didn't catch this earlier.  My patches caused this problem.  I
>  > was careful to make sure the static method had stayed the same in
>  > Codec-1.3 and Codec-1.4, but I just never thought people would
>  > actually write things like this:
>  >
>  > new Base64().encode()   !!!
>  >
>  > Just didn't enter my mind to test that to compare output of 1.3 vs
>  > 1.4.  Very sorry.  :-(
>  >
>  >
>
>
>  --
>  yours,
>
>  Julius Davies
>  250-592-2284 (Home)
>  250-893-4579 (Mobile)
>  http://juliusdavies.ca/logging.html
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message