commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <juliusdav...@gmail.com>
Subject Re: [codec] regression in 1.4
Date Wed, 02 Dec 2009 03:41:40 GMT
Hi,

Thanks for looking at this issue!

If the patch gets accepted then this would become the way to specify
that you want the codec-1.4 (bad) behaviour:

Base64 b64 = new Base64(76);





On Tue, Dec 1, 2009 at 6:12 PM, sebb <sebbaz@gmail.com> wrote:
> On 02/12/2009, Gary Gregory <GGregory@seagullsoftware.com> wrote:
>> What about making the offending class configurable for 1.3 or 1.4 behavior?
>
> How? System property? That's not usually advisable for a library.
>
>>  The issue becomes which should be the default behavior...
>>
>>  Should the default behavior be the one closest to the B64 spec?
>
> As far as I can tell
>
> new Base64(0).encode()
> is the same as
> Base64.encodeBas64()
>
> If the parameterless ctor were changed to set the line length to 0,
> then users wishing to have the existing behaviour of that ctor would
> need to use new Base64(false).
>
>>
>>  Gary
>>
>>
>>  > -----Original Message-----
>>  > From: sebb [mailto:sebbaz@gmail.com]
>>  > Sent: Tuesday, December 01, 2009 17:18
>>  > To: Commons Developers List
>>  > Subject: Re: [codec] regression in 1.4
>>  >
>>  > 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


Mime
View raw message