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