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 <seb...@gmail.com> wrote: > On 02/12/2009, Gary Gregory <ggreg...@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:seb...@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 <juliusdav...@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 >> > <juliusdav...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org