You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Julius Davies <ju...@gmail.com> on 2009/11/23 21:24:40 UTC
[codec] regression in 1.4
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
Re: [codec] regression in 1.4
Posted by Julius Davies <ju...@gmail.com>.
By the way, if we do start the ball rolling for a 1.4.1 release, I
nominate myself to better document the changes between 1.3 <---> 1.4.1
kind of along the lines of the discussion over on CODEC-91:
https://issues.apache.org/jira/browse/CODEC-91
On Tue, Dec 1, 2009 at 7:41 PM, Julius Davies <ju...@gmail.com> wrote:
> 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);
>
>
>
--
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
Re: [codec] regression in 1.4
Posted by Julius Davies <ju...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 02/12/2009, Gary Gregory <GG...@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 <ju...@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
>> > <ju...@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
Re: [codec] regression in 1.4
Posted by Julius Davies <ju...@gmail.com>.
Nice patch, Sebb! Now just combine it with the JUnits from mine! :-p
yours,
Julius
On Wed, Dec 2, 2009 at 5:49 PM, sebb <se...@gmail.com> wrote:
> On 02/12/2009, Julius Davies <ju...@gmail.com> wrote:
>> This current JUnit test "kinda/sorta" covers the static method for non-chunking:
>>
>> public void testSingletons() {
>> assertEquals("AA==", new String(Base64.encodeBase64(new byte[]{(byte) 0})));
>> assertEquals("AQ==", new String(Base64.encodeBase64(new byte[]{(byte) 1})));
>> [...]
>> }
>>
>>
>> Especially when compared to this test later on!
>>
>> public void testSingletonsChunked() {
>> assertEquals("AA==\r\n", new String(Base64.encodeBase64Chunked(new
>> byte[]{(byte) 0})));
>> assertEquals("AQ==\r\n", new String(Base64.encodeBase64Chunked(new
>> byte[]{(byte) 1})));
>> assertEquals("Ag==\r\n", new String(Base64.encodeBase64Chunked(new
>> byte[]{(byte) 2})));
>> [...]
>> }
>>
>>
>> The patch I attached to CODEC-89 obviously includes JUnit tests to
>> guard against improper chunking for the new Base64().encode() problem
>> we're currently looking at. I agree with Sebb that some more JUnits
>> to guard against the static method accidentally chunking output in the
>> future would be a good idea.
>>
>> Has any committer had a chance to look at the patch yet?
>
> Just had a look (twice!) - see my comments added to the JIRA issue.
>
>> yours,
>>
>>
>> Julius
>>
>>
>>
>>
>> On Wed, Dec 2, 2009 at 11:18 AM, sebb <se...@gmail.com> wrote:
>> > On 02/12/2009, Mat Booth <ap...@matbooth.co.uk> wrote:
>> >> 2009/12/2 sebb <se...@gmail.com>:
>> >>
>> >> > On 02/12/2009, Gary Gregory <GG...@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).
>> >> >
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> I've only just found this thread. As I said on the ticket, I'd be
>> >> content if you can get the old behaviour with that method (which I now
>> >> know is possible by passing 0, thanks for that Sebb) and behavioural
>> >> changes such as this were documented in the release notes.
>> >>
>> >> If these behavioural changes are documented some place, then I can
>> >> talk to the consumers of commons-codec in Fedora and make sure they
>> >> are doing the Right Thing and submit patches upstream where necessary.
>> >
>> > [Perhaps it's stating the obvious, but]
>> >
>> > If they are currently doing
>> >
>> > new Base64().encode()
>> >
>> > and expecting the old (1.3) behaviour, then they can of course use the
>> > static encodeBase64() method instead. This will work with 1.3 and 1.4
>> > and 1.4.1 (and hopefully forever)
>> >
>> > I guess we should add a test that checks that the static encode method
>> > does not chunk.
>> > [There does not seem to be such a test at present] I'll add this to JIRA.
>> >
>> >> Thanks,
>> >> Mat
>> >>
>> >>
>> >> --
>> >> Mat Booth
--
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
Re: [codec] regression in 1.4
Posted by sebb <se...@gmail.com>.
On 02/12/2009, Julius Davies <ju...@gmail.com> wrote:
> This current JUnit test "kinda/sorta" covers the static method for non-chunking:
>
> public void testSingletons() {
> assertEquals("AA==", new String(Base64.encodeBase64(new byte[]{(byte) 0})));
> assertEquals("AQ==", new String(Base64.encodeBase64(new byte[]{(byte) 1})));
> [...]
> }
>
>
> Especially when compared to this test later on!
>
> public void testSingletonsChunked() {
> assertEquals("AA==\r\n", new String(Base64.encodeBase64Chunked(new
> byte[]{(byte) 0})));
> assertEquals("AQ==\r\n", new String(Base64.encodeBase64Chunked(new
> byte[]{(byte) 1})));
> assertEquals("Ag==\r\n", new String(Base64.encodeBase64Chunked(new
> byte[]{(byte) 2})));
> [...]
> }
>
>
> The patch I attached to CODEC-89 obviously includes JUnit tests to
> guard against improper chunking for the new Base64().encode() problem
> we're currently looking at. I agree with Sebb that some more JUnits
> to guard against the static method accidentally chunking output in the
> future would be a good idea.
>
> Has any committer had a chance to look at the patch yet?
Just had a look (twice!) - see my comments added to the JIRA issue.
> yours,
>
>
> Julius
>
>
>
>
> On Wed, Dec 2, 2009 at 11:18 AM, sebb <se...@gmail.com> wrote:
> > On 02/12/2009, Mat Booth <ap...@matbooth.co.uk> wrote:
> >> 2009/12/2 sebb <se...@gmail.com>:
> >>
> >> > On 02/12/2009, Gary Gregory <GG...@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).
> >> >
> >>
> >>
> >> Hi all,
> >>
> >> I've only just found this thread. As I said on the ticket, I'd be
> >> content if you can get the old behaviour with that method (which I now
> >> know is possible by passing 0, thanks for that Sebb) and behavioural
> >> changes such as this were documented in the release notes.
> >>
> >> If these behavioural changes are documented some place, then I can
> >> talk to the consumers of commons-codec in Fedora and make sure they
> >> are doing the Right Thing and submit patches upstream where necessary.
> >
> > [Perhaps it's stating the obvious, but]
> >
> > If they are currently doing
> >
> > new Base64().encode()
> >
> > and expecting the old (1.3) behaviour, then they can of course use the
> > static encodeBase64() method instead. This will work with 1.3 and 1.4
> > and 1.4.1 (and hopefully forever)
> >
> > I guess we should add a test that checks that the static encode method
> > does not chunk.
> > [There does not seem to be such a test at present] I'll add this to JIRA.
> >
> >> Thanks,
> >> Mat
> >>
> >>
> >> --
> >> Mat Booth
> >>
> >> ---------------------------------------------------------------------
> >>
> >> 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
> >
> >
>
>
>
>
> --
>
> 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
Re: [codec] regression in 1.4
Posted by Julius Davies <ju...@gmail.com>.
This current JUnit test "kinda/sorta" covers the static method for non-chunking:
public void testSingletons() {
assertEquals("AA==", new String(Base64.encodeBase64(new byte[]{(byte) 0})));
assertEquals("AQ==", new String(Base64.encodeBase64(new byte[]{(byte) 1})));
[...]
}
Especially when compared to this test later on!
public void testSingletonsChunked() {
assertEquals("AA==\r\n", new String(Base64.encodeBase64Chunked(new
byte[]{(byte) 0})));
assertEquals("AQ==\r\n", new String(Base64.encodeBase64Chunked(new
byte[]{(byte) 1})));
assertEquals("Ag==\r\n", new String(Base64.encodeBase64Chunked(new
byte[]{(byte) 2})));
[...]
}
The patch I attached to CODEC-89 obviously includes JUnit tests to
guard against improper chunking for the new Base64().encode() problem
we're currently looking at. I agree with Sebb that some more JUnits
to guard against the static method accidentally chunking output in the
future would be a good idea.
Has any committer had a chance to look at the patch yet?
yours,
Julius
On Wed, Dec 2, 2009 at 11:18 AM, sebb <se...@gmail.com> wrote:
> On 02/12/2009, Mat Booth <ap...@matbooth.co.uk> wrote:
>> 2009/12/2 sebb <se...@gmail.com>:
>>
>> > On 02/12/2009, Gary Gregory <GG...@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).
>> >
>>
>>
>> Hi all,
>>
>> I've only just found this thread. As I said on the ticket, I'd be
>> content if you can get the old behaviour with that method (which I now
>> know is possible by passing 0, thanks for that Sebb) and behavioural
>> changes such as this were documented in the release notes.
>>
>> If these behavioural changes are documented some place, then I can
>> talk to the consumers of commons-codec in Fedora and make sure they
>> are doing the Right Thing and submit patches upstream where necessary.
>
> [Perhaps it's stating the obvious, but]
>
> If they are currently doing
>
> new Base64().encode()
>
> and expecting the old (1.3) behaviour, then they can of course use the
> static encodeBase64() method instead. This will work with 1.3 and 1.4
> and 1.4.1 (and hopefully forever)
>
> I guess we should add a test that checks that the static encode method
> does not chunk.
> [There does not seem to be such a test at present] I'll add this to JIRA.
>
>> Thanks,
>> Mat
>>
>>
>> --
>> Mat Booth
>>
>> ---------------------------------------------------------------------
>>
>> 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
>
>
--
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
Re: [codec] regression in 1.4
Posted by sebb <se...@gmail.com>.
On 02/12/2009, Mat Booth <ap...@matbooth.co.uk> wrote:
> 2009/12/2 sebb <se...@gmail.com>:
>
> > On 02/12/2009, Gary Gregory <GG...@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).
> >
>
>
> Hi all,
>
> I've only just found this thread. As I said on the ticket, I'd be
> content if you can get the old behaviour with that method (which I now
> know is possible by passing 0, thanks for that Sebb) and behavioural
> changes such as this were documented in the release notes.
>
> If these behavioural changes are documented some place, then I can
> talk to the consumers of commons-codec in Fedora and make sure they
> are doing the Right Thing and submit patches upstream where necessary.
[Perhaps it's stating the obvious, but]
If they are currently doing
new Base64().encode()
and expecting the old (1.3) behaviour, then they can of course use the
static encodeBase64() method instead. This will work with 1.3 and 1.4
and 1.4.1 (and hopefully forever)
I guess we should add a test that checks that the static encode method
does not chunk.
[There does not seem to be such a test at present] I'll add this to JIRA.
> Thanks,
> Mat
>
>
> --
> Mat Booth
>
> ---------------------------------------------------------------------
>
> 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
Re: [codec] regression in 1.4
Posted by Mat Booth <ap...@matbooth.co.uk>.
2009/12/2 sebb <se...@gmail.com>:
> On 02/12/2009, Gary Gregory <GG...@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).
>
Hi all,
I've only just found this thread. As I said on the ticket, I'd be
content if you can get the old behaviour with that method (which I now
know is possible by passing 0, thanks for that Sebb) and behavioural
changes such as this were documented in the release notes.
If these behavioural changes are documented some place, then I can
talk to the consumers of commons-codec in Fedora and make sure they
are doing the Right Thing and submit patches upstream where necessary.
Thanks,
Mat
--
Mat Booth
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] regression in 1.4
Posted by sebb <se...@gmail.com>.
On 02/12/2009, Gary Gregory <GG...@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 <ju...@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
> > <ju...@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
>
>
> ---------------------------------------------------------------------
> 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
RE: [codec] regression in 1.4
Posted by Gary Gregory <GG...@seagullsoftware.com>.
What about making the offending class configurable for 1.3 or 1.4 behavior?
The issue becomes which should be the default behavior...
Should the default behavior be the one closest to the B64 spec?
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 <ju...@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
> <ju...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] regression in 1.4
Posted by sebb <se...@gmail.com>.
On 02/12/2009, Julius Davies <ju...@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 <ju...@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
Re: [codec] regression in 1.4
Posted by Julius Davies <ju...@gmail.com>.
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?
yours,
Julius
On Mon, Nov 23, 2009 at 12:24 PM, Julius Davies <ju...@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