You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsw.com> on 2004/06/02 01:05:34 UTC
RE: [codec] base64Codec.decode and DecoderException
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
Re: [codec] base64Codec.decode and DecoderException
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
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" <rh...@isisnetworks.net>
To: "Jakarta Commons Developers List" <co...@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
Re: [codec] base64Codec.decode and DecoderException
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
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