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 <seb...@gmail.com> wrote: > On 02/12/2009, Julius Davies <juliusdav...@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 <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 -- 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