Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of juliusdavies@gmail.com
 designates 209.85.222.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=mQbg/03jyw6DTLdxRvGqaXr8FBnVL6lxXpnK4r8xiVuOir5pslaDoA1nm5IPgCwtag
         RbtdtRG6OVy2nqIgXPphqDDx7o8O9UYfFWWi9H3UT3fJ5PmnEriTxLHr//97vt9l8raf
         6mO74SKrddvpeh2XHcWHm3Ae3iEZ9Y1a73rmk=
MIME-Version: 1.0
In-Reply-To: <25aac9fc0912021749i6452a1b5g23d4c8b898bd2064@mail.gmail.com>
References: <598ad5b50911231224q3ee94981l67ca7012643be016@mail.gmail.com>
	 <598ad5b50912011626n546d60f6s75e17043dd19658a@mail.gmail.com>
	 <25aac9fc0912011718w41856a85i1559c0589a1aadcd@mail.gmail.com>
	 <94C476C03BFF5E42AC3518FDAC9643C4E2DEA1F527@HQMAIL.rocketsoftware.com>
	 <25aac9fc0912011812h4f67a8fcxa6cfc8c5d8c61a93@mail.gmail.com>
	 <9497e9990912021053h78e35369yca20ea022910f751@mail.gmail.com>
	 <25aac9fc0912021118m2d74d41cnc393b78cc622fdb6@mail.gmail.com>
	 <598ad5b50912021420s6ea90cd9l18273c4029e6b31f@mail.gmail.com>
	 <25aac9fc0912021749i6452a1b5g23d4c8b898bd2064@mail.gmail.com>
Date: Wed, 2 Dec 2009 20:52:49 -0800
Message-ID: <598ad5b50912022052w22fa3e67ye132f20aeefff9f7@mail.gmail.com>
Subject: Re: [codec] regression in 1.4
From: Julius Davies <juliusdavies@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <sebbaz@gmail.com> wrote:
> On 02/12/2009, Julius Davies <juliusdavies@gmail.com> wrote:
>> This current JUnit test "kinda/sorta" covers the static method for non-c=
hunking:
>>
>> =A0public void testSingletons() {
>> =A0 assertEquals("AA=3D=3D", new String(Base64.encodeBase64(new byte[]{(=
byte) 0})));
>> =A0 assertEquals("AQ=3D=3D", new String(Base64.encodeBase64(new byte[]{(=
byte) 1})));
>> =A0 [...]
>> =A0}
>>
>>
>> =A0Especially when compared to this test later on!
>>
>> =A0public void testSingletonsChunked() {
>> =A0 assertEquals("AA=3D=3D\r\n", new String(Base64.encodeBase64Chunked(n=
ew
>> =A0byte[]{(byte) 0})));
>> =A0 assertEquals("AQ=3D=3D\r\n", new String(Base64.encodeBase64Chunked(n=
ew
>> =A0byte[]{(byte) 1})));
>> =A0 assertEquals("Ag=3D=3D\r\n", new String(Base64.encodeBase64Chunked(n=
ew
>> =A0byte[]{(byte) 2})));
>> =A0 [...]
>> =A0}
>>
>>
>> =A0The patch I attached to CODEC-89 obviously includes JUnit tests to
>> =A0guard against improper chunking for the new Base64().encode() problem
>> =A0we're currently looking at. =A0I agree with Sebb that some more JUnit=
s
>> =A0to guard against the static method accidentally chunking output in th=
e
>> =A0future would be a good idea.
>>
>> =A0Has any committer had a chance to look at the patch yet?
>
> Just had a look (twice!) - see my comments added to the JIRA issue.
>
>> =A0yours,
>>
>>
>> =A0Julius
>>
>>
>>
>>
>> =A0On Wed, Dec 2, 2009 at 11:18 AM, sebb <sebbaz@gmail.com> wrote:
>> =A0> On 02/12/2009, Mat Booth <apache@matbooth.co.uk> wrote:
>> =A0>> 2009/12/2 sebb <sebbaz@gmail.com>:
>> =A0>>
>> =A0>> > On 02/12/2009, Gary Gregory <GGregory@seagullsoftware.com> wrote=
:
>> =A0>> =A0>> What about making the offending class configurable for 1.3 o=
r 1.4 behavior?
>> =A0>> =A0>
>> =A0>> =A0> How? System property? That's not usually advisable for a libr=
ary.
>> =A0>> =A0>
>> =A0>> =A0>> =A0The issue becomes which should be the default behavior...
>> =A0>> =A0>>
>> =A0>> =A0>> =A0Should the default behavior be the one closest to the B64=
 spec?
>> =A0>> =A0>
>> =A0>> =A0> As far as I can tell
>> =A0>> =A0>
>> =A0>> =A0> new Base64(0).encode()
>> =A0>> =A0> is the same as
>> =A0>> =A0> Base64.encodeBas64()
>> =A0>> =A0>
>> =A0>> =A0> If the parameterless ctor were changed to set the line length=
 to 0,
>> =A0>> =A0> then users wishing to have the existing behaviour of that cto=
r would
>> =A0>> =A0> need to use new Base64(false).
>> =A0>> =A0>
>> =A0>>
>> =A0>>
>> =A0>> Hi all,
>> =A0>>
>> =A0>> =A0I've only just found this thread. As I said on the ticket, I'd =
be
>> =A0>> =A0content if you can get the old behaviour with that method (whic=
h I now
>> =A0>> =A0know is possible by passing 0, thanks for that Sebb) and behavi=
oural
>> =A0>> =A0changes such as this were documented in the release notes.
>> =A0>>
>> =A0>> =A0If these behavioural changes are documented some place, then I =
can
>> =A0>> =A0talk to the consumers of commons-codec in Fedora and make sure =
they
>> =A0>> =A0are doing the Right Thing and submit patches upstream where nec=
essary.
>> =A0>
>> =A0> [Perhaps it's stating the obvious, but]
>> =A0>
>> =A0> If they are currently doing
>> =A0>
>> =A0> new Base64().encode()
>> =A0>
>> =A0> and expecting the old (1.3) behaviour, then they can of course use =
the
>> =A0> static encodeBase64() method instead. This will work with 1.3 and 1=
.4
>> =A0> and 1.4.1 (and hopefully forever)
>> =A0>
>> =A0> I guess we should add a test that checks that the static encode met=
hod
>> =A0> does not chunk.
>> =A0> [There does not seem to be such a test at present] I'll add this to=
 JIRA.
>> =A0>
>> =A0>> =A0Thanks,
>> =A0>> =A0Mat
>> =A0>>
>> =A0>>
>> =A0>> =A0--
>> =A0>> =A0Mat Booth


--=20
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