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 sebbaz@gmail.com designates
 209.85.220.225 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;
        b=OIUrPjhHMKCEPWlSK75m2bQILd2SACCf6xeQioLbrC4RNVf6CSUeZC5fbLOaQ+axP7
         B0jNKZIQV5mYVXAqghKvRJNSIaJ/GqvaPqkYw7wEEvIqNpESa8HmaP6fKF1yrnYTFRb5
         edfGsj8U/2f4iVwv/tFpPtll7ARgYybSWW4KU=
MIME-Version: 1.0
In-Reply-To: <598ad5b50912021420s6ea90cd9l18273c4029e6b31f@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>
Date: Thu, 3 Dec 2009 01:49:25 +0000
Message-ID: <25aac9fc0912021749i6452a1b5g23d4c8b898bd2064@mail.gmail.com>
Subject: Re: [codec] regression in 1.4
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 02/12/2009, Julius Davies <juliusdavies@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 <sebbaz@gmail.com> wrote:
>  > On 02/12/2009, Mat Booth <apache@matbooth.co.uk> wrote:
>  >> 2009/12/2 sebb <sebbaz@gmail.com>:
>  >>
>  >> > On 02/12/2009, Gary Gregory <GGregory@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