commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thad Humphries <thad.humphr...@gmail.com>
Subject Re: [codec] problem with Base64OutputStream
Date Sun, 17 Feb 2013 16:05:10 GMT
On Sun, Feb 17, 2013 at 10:03 AM, William Speirs <wspeirs@apache.org> wrote:

> Yea, it looks like 2 versions of the library are in-play here: one with the
> proper constructor and another without.
>
> Bill-
>
>
> On Sun, Feb 17, 2013 at 9:55 AM, Thomas Neidhart
> <thomas.neidhart@gmail.com>wrote:
>
> > On 02/17/2013 03:20 PM, Thad Humphries wrote:
> > > On Sun, Feb 17, 2013 at 4:56 AM, Thomas Neidhart
> > > <thomas.neidhart@gmail.com>wrote:
> > >
> > >> On 02/17/2013 12:13 AM, Thad Humphries wrote:
> > >>> I am using Commons Codec v1.7 to Base64 encode a TIFF file for
> writing
> > to
> > >>> an XML file as CDATA. Simple:
> > >>>
> > >>>         File file = new File(fileName);
> > >>>         FileInputStream fis = new FileInputStream(file);
> > >>>         ByteArrayOutputStream baos = new ByteArrayOutputStream();
> > >>>         Base64OutputStream b64os = new Base64OutputStream(baos);
> > >>>         int bufSize = 8 * 1024;
> > >>>         byte [] buffer = new byte[bufSize];
> > >>>         int count;
> > >>>         while ((count = fis.read(buffer, 0, bufSize)) != -1)
> > >>>           b64os.write(buffer, 0, count);
> > >>>         fis.close();
> > >>>         baos.flush();
> > >>>         b64os.close();
> > >>>         baos.close();
> > >>>         xtw.writeCData(new String(baos.toByteArray()));
> > >>>
> > >>> However I'm concerned that a future version Commons Codec of might
> not
> > >>> default to chunked output. So I'd like to swap
> > >>>
> > >>>         Base64OutputStream b64os = new Base64OutputStream(baos);
> > >>>
> > >>> for
> > >>>
> > >>>         byte [] eol = {0xD, 0xA};
> > >>>         Base64OutputStream b64os = new Base64OutputStream(baos, true,
> > 76,
> > >>> eol);
> > >>>
> > >>> However when I do this, the program crashes out on creating "new
> > >>> Base64OutputStream(...)". If fact, it skips right past a catch on
> > >> Exception
> > >>> and goes directly to finally (honest--my logger shows nothing and
> I've
> > >>> watched this dozens of times in Eclipse's deugger).
> > >>>
> > >>> Am I doing something wrong?
> > >>
> > >> Hi Thad,
> > >>
> > >> I just tried your example and this works pretty fine for me. Could you
> > >> please post the exception you are getting?
> > >>
> > >> Thomas
> > >>
> > >
> > > Hi Thomas,
> > >
> > > Thanks for the response. The call does not catch as an Exception, but
> > just
> > > now I found that it catches as a Throwable. My log4j log is below. Line
> > > 1703 is where I instantiate Base64OutputStream:
> > >
> > > Base64OutputStream b64os = new Base64OutputStream(baos, true, 76, eol);
> > >
> > > From the log.
> > >
> > > java.lang.VerifyError: (class:
> > > org/apache/commons/codec/binary/Base64OutputStream, method: <init>
> > > signature: (Ljava/io/OutputStream;ZI[B)V) Incompatible argument to
> > function
> >
> > For me this looks like you have different classpath settings in your
> > development / compile and runtime environment, but this seems to be more
> > related to GWT so I may not be able to help you further than that.
> >
> > Thomas
>

Thanks Thomas and Bill. That looks to be it. As you can see I'm developing
with the Google Web Toolkit (GWT). Unbeknownst to me one of the JARs
required during development--but not required for deployment--includes
org.apache.james.mime4j which includes a Base64OutputStream class. If I
move that jar--gwt-dev.jar--below my Commons jar in Eclipse's build order,
it runs fine. Just to be sure, I'll put the Commons Codec jar before
gwt-dev.jar
in my build.xml as well.

-- 
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v, 121-24)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message