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" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > >>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: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
