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 > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
