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 <seb...@gmail.com> wrote:
> On 02/12/2009, Mat Booth <apa...@matbooth.co.uk> wrote:
>> 2009/12/2 sebb <seb...@gmail.com>:
>>
>> > 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).
>> >
>>
>>
>> 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-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
>
>
--
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
