commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: [codec] base64Codec.decode and DecoderException
Date Fri, 04 Jun 2004 04:04:05 GMT
So, if I am following this ... we need a codec-1.1 module/project (in Gump)
against the CODEC_1_1 tag of codec that gives us frozen 1.1 code. Ok, that
ought be doable.

If nobody sees a problem with this approach, I'll give it a shot.

regards,

Adam
----- Original Message ----- 
From: "Ryan Hoegg" <rhoegg@isisnetworks.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Thursday, June 03, 2004 8:41 PM
Subject: Re: [codec] base64Codec.decode and DecoderException


> Hi,
>
> I'd guess not.  In Codec 1.1 the (checked) DecoderException was thrown.
> XML-RPC 2.0 alpha (HEAD) depends on version 1.1 of codec with no known
> issues.
>
> I'd be surprised if we updated to 1.2 this summer.  Our stable branch
> (1.2) has no current or planned dependency on codec because we had our
> own Base64 implementation.  I probably already mentioned that we only
> need Base64, so we might end up deciding against having a codec
> dependency.  Not long ago the Maven team encountered the same situation
> and they decided to copy the Base64 source rather than to depend on
> codec.  I'd prefer not to follow suit for a lot of the same reasons we
> decided to create a shared Base64 implementation in the first place
> (early 2002 in the sandbox).  For various reasons xmlrpc doesn't move
> very quickly, especially by jakarta standards.  So for the time being,
> we'll probably stick with codec 1.1.
>
> Cheers,
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net/
>
> Gary Gregory wrote:
>
> >Has this been resolved within "build_ws-xmlrpc_ws-xmlrpc"?
> >
> >I do not see the compile error mentioned in the message below in the
> >page:
> >
> >
> >
> >http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
> >s-
> >
> >
> >>xmlrpc_ws-xmlrpc.html
> >>
> >>
> >
> >Thank you,
> >Gary
> >
> >
> >
> >>-----Original Message-----
> >>From: Adam R. B. Jack [mailto:ajack@trysybase.com]
> >>Sent: Tuesday, May 25, 2004 09:44
> >>To: Jakarta Commons Developers List
> >>Subject: [codec] base64Codec.decode and DecoderException
> >>
> >>Folks,
> >>
> >>An interested compatibility issue has surfaced from this:
> >>
> >>
> >>
> >>
> >http://brutus.apache.org:8080/gump/ws-xmlrpc/ws-xmlrpc/gump_work/build_w
> >s-
> >
> >
> >>xmlrpc_ws-xmlrpc.html
> >>
> >>/usr/local/gump/public/workspace/ws-
> >>xmlrpc/src/java/org/apache/xmlrpc/Defaul
> >>tTypeFactory.java:133: exception
> >>
> >>
> >org.apache.commons.codec.DecoderException
> >
> >
> >>is never thrown in body of corresponding try statement
> >>    [javac]         catch (DecoderException e) {
> >>    [javac]         ^
> >>
> >>This is the code:
> >>
> >> public Object createBase64(String cdata)
> >>    {
> >>        try {
> >>            return base64Codec.decode(cdata.getBytes());
> >>        }
> >>        catch (DecoderException e) {
> >>            //TODO: consider throwing an exception here?
> >>            return new byte[0];
> >>        }
> >>    }
> >>
> >>Now since exceptions are not part of the signature of methods, there
> >>
> >>
> >is
> >
> >
> >>probably no runtime issue here. If the exception is not going to be
> >>
> >>
> >thrown
> >
> >
> >>that is the same as it not actually being thrown, I guess. Still,
> >>
> >>
> >there is
> >
> >
> >>a
> >>compile time problem and if one removes the catch they can't compile
> >>against
> >>older codec (assuming that was declared to throw it).
> >>
> >>Can somebody provide the background information on this exception,
> >>
> >>
> >from
> >
> >
> >>this
> >>method, and when (releases) it might've been available and removed? If
> >>this
> >>exception is never to be thrown again (and better, if it isn't thrown
> >>
> >>
> >in
> >
> >
> >>currently released code) then maybe we can just ask the ws-xmlrpc
> >>
> >>
> >folks to
> >
> >
> >>update.
> >>
> >>BTW: I don't think there is a way to turn off this compiler error, is
> >>there?
> >>Would that be appropriate, even if possible?
> >>
> >>regards,
> >>
> >>Adam
> >>--
> >>Experience the Unwired Enterprise:
> >>http://www.sybase.com/unwiredenterprise
> >>Try Sybase: http://www.try.sybase.com
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message