commons-codec version incompatiblity

[Ryan Bloom <rb...@redhat.com>]

I am trying to get xmlrpc building, and I am running into problems with 
commons-codec 1.2.

Basically, the problem is in calling Base64.encode and .decode.  
Essentially, the code 1.1 release had two encode and decode methods, one 
that accepted a byte[] and the other accepted an Object.  In both cases, 
Encoder/Decoder Exceptions were thrown if the argument wasn't a byte[].  
In commons-codec 1.2, both methods still exist, but the one that accepts a 
byte[] no longer throws the exception.

So, I have one option (which kind of sucks), I can cast the byte[] to an 
Object in the calls to encode/decode to retain compatibility between codec 
1.1 and 1.2.

Thoughts?  I can have a patch ready in a few seconds if it will be 
accepted.

Ryan

Re: commons-codec version incompatiblity

[Ryan Bloom <rb...@redhat.com>]

On Tue, 15 Jun 2004, Adam Jack wrote:

> 
> >
> > I am trying to get xmlrpc building, and I am running into problems with
> > commons-codec 1.2.
> 
> Yup, Gump found these a few weeks ago. Basically the view from this
> list/community (of which I am just an observer, not a participant) is -- use
> codec 1.1, don't move up. Is that option not available to you?

No, that isn't really an option, because I am trying to use jpackage 
packages, and jpackage only has codec 1.2.  But, more importantly, for 
something with such a trivial fix we should just fix it.

Ryan

Re: commons-codec version incompatiblity

[Adam Jack <aj...@trysybase.com>]

>
> I am trying to get xmlrpc building, and I am running into problems with
> commons-codec 1.2.

Yup, Gump found these a few weeks ago. Basically the view from this
list/community (of which I am just an observer, not a participant) is -- use
codec 1.1, don't move up. Is that option not available to you?

regards

Adam

Re: commons-codec version incompatiblity

[Ryan Bloom <rb...@redhat.com>]

Nevermind, Jochen already posted one.

Ryan

On Wed, 16 Jun 2004, Ryan Bloom wrote:

> 
> OK, I'll post the patch today.
> 
> Ryan
> 
> On Tue, 15 Jun 2004, Jochen Wiedmann wrote:
> 
> > On Di, 2004-06-15 at 19:01, Ryan Bloom wrote:
> > 
> > > So, I have one option (which kind of sucks), I can cast the byte[] to an 
> > > Object in the calls to encode/decode to retain compatibility between codec 
> > > 1.1 and 1.2.
> > 
> > Let it suck. :-) If you do that change, it will prevent a lot of hazzle
> > and questions in the future.
> > 
> > 
> > Jochen
> > 
> 

Re: commons-codec version incompatiblity

[Ryan Bloom <rb...@redhat.com>]

OK, I'll post the patch today.

Ryan

On Tue, 15 Jun 2004, Jochen Wiedmann wrote:

> On Di, 2004-06-15 at 19:01, Ryan Bloom wrote:
> 
> > So, I have one option (which kind of sucks), I can cast the byte[] to an 
> > Object in the calls to encode/decode to retain compatibility between codec 
> > 1.1 and 1.2.
> 
> Let it suck. :-) If you do that change, it will prevent a lot of hazzle
> and questions in the future.
> 
> 
> Jochen
> 

Re: Running the tests

[Sebastian Dransfeld <se...@sintef.no>]

On Wed, 2004-06-16 at 15:59, Ryan Bloom wrote:
> On Wed, 16 Jun 2004, Sebastian Dransfeld wrote:
> 
> > On Wed, 2004-06-16 at 15:20, Ryan Bloom wrote:
> > > On Wed, 16 Jun 2004, Jochen Wiedmann wrote:
> > > 
> > > > On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> > > > 
> > > > > For some reason, just running ant test is failing one test for me.  
> > > > > Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to 
> > > > > connect to a server.  I would have thought that "ant test" would have run 
> > > > > the server before trying to run the client, but that doesn't seem to be 
> > > > > the case for this test.
> > > > > 
> > > > > I tried running the echo sample app on port 8081, and that gets this test 
> > > > > passing, but a different test fails, because port 8081 is taked already.  
> > > > > There must be a simple way to run the tests and have them pass, but what 
> > > > > is it?
> > > > 
> > > > I had the same problem today with more than one test and found, that I
> > > > had to repeat the tests multiple times and per test. They all work
> > > > separately, it seems, but not together.
> > > 
> > > That's insane!  I need an XMLRPC library for a project that I am working 
> > > on, and I would really like to use this one, but I am having a hard time 
> > > trusting it currently.  I am going to start by going through and cleaning 
> > > up all of the deprecated method calls.  Then I am going to put in support 
> > > for the Collections framework instead of using Vector everywhere.
> > > 
> > > Ryan
> > 
> > If you don't need secure xml-rpc, I posted a patch earlier to change the
> > library to use the Collection framework. The patch was against cvs head.
> 
> Why doesn't it work with secure xml-rpc?  Why hasn't it been committed 
> yet?
> 
> Ryan

I didn't feel like fixing secure xml-rpc, because the code has a lot of
warnings and deprecations that should be fixed in addition to the move
to Collections.

Why it hasn't been committed is beyond me. Seems like few external
patches gets accepted.

Sebastian

Re: Running the tests

[Ryan Bloom <rb...@redhat.com>]

On Wed, 16 Jun 2004, Sebastian Dransfeld wrote:

> On Wed, 2004-06-16 at 15:20, Ryan Bloom wrote:
> > On Wed, 16 Jun 2004, Jochen Wiedmann wrote:
> > 
> > > On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> > > 
> > > > For some reason, just running ant test is failing one test for me.  
> > > > Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to 
> > > > connect to a server.  I would have thought that "ant test" would have run 
> > > > the server before trying to run the client, but that doesn't seem to be 
> > > > the case for this test.
> > > > 
> > > > I tried running the echo sample app on port 8081, and that gets this test 
> > > > passing, but a different test fails, because port 8081 is taked already.  
> > > > There must be a simple way to run the tests and have them pass, but what 
> > > > is it?
> > > 
> > > I had the same problem today with more than one test and found, that I
> > > had to repeat the tests multiple times and per test. They all work
> > > separately, it seems, but not together.
> > 
> > That's insane!  I need an XMLRPC library for a project that I am working 
> > on, and I would really like to use this one, but I am having a hard time 
> > trusting it currently.  I am going to start by going through and cleaning 
> > up all of the deprecated method calls.  Then I am going to put in support 
> > for the Collections framework instead of using Vector everywhere.
> > 
> > Ryan
> 
> If you don't need secure xml-rpc, I posted a patch earlier to change the
> library to use the Collection framework. The patch was against cvs head.

Why doesn't it work with secure xml-rpc?  Why hasn't it been committed 
yet?

Ryan

Re: Running the tests

[Sebastian Dransfeld <se...@sintef.no>]

On Wed, 2004-06-16 at 15:20, Ryan Bloom wrote:
> On Wed, 16 Jun 2004, Jochen Wiedmann wrote:
> 
> > On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> > 
> > > For some reason, just running ant test is failing one test for me.  
> > > Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to 
> > > connect to a server.  I would have thought that "ant test" would have run 
> > > the server before trying to run the client, but that doesn't seem to be 
> > > the case for this test.
> > > 
> > > I tried running the echo sample app on port 8081, and that gets this test 
> > > passing, but a different test fails, because port 8081 is taked already.  
> > > There must be a simple way to run the tests and have them pass, but what 
> > > is it?
> > 
> > I had the same problem today with more than one test and found, that I
> > had to repeat the tests multiple times and per test. They all work
> > separately, it seems, but not together.
> 
> That's insane!  I need an XMLRPC library for a project that I am working 
> on, and I would really like to use this one, but I am having a hard time 
> trusting it currently.  I am going to start by going through and cleaning 
> up all of the deprecated method calls.  Then I am going to put in support 
> for the Collections framework instead of using Vector everywhere.
> 
> Ryan

If you don't need secure xml-rpc, I posted a patch earlier to change the
library to use the Collection framework. The patch was against cvs head.

Sebastian

Re: Running the tests

[Jochen Wiedmann <jo...@freenet.de>]

On Mi, 2004-06-16 at 15:20, Ryan Bloom wrote:

> That's insane!  I need an XMLRPC library for a project that I am working 
> on, and I would really like to use this one, but I am having a hard time 
> trusting it currently.  I am going to start by going through and cleaning 
> up all of the deprecated method calls.  Then I am going to put in support 
> for the Collections framework instead of using Vector everywhere.

+1 :-)

(And, while you are at it, don't forget Hashtable => HashMap and Stack
=> ArrayList.)

Re: Running the tests

[Ryan Bloom <rb...@redhat.com>]

On Wed, 16 Jun 2004, Jochen Wiedmann wrote:

> On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:
> 
> > For some reason, just running ant test is failing one test for me.  
> > Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to 
> > connect to a server.  I would have thought that "ant test" would have run 
> > the server before trying to run the client, but that doesn't seem to be 
> > the case for this test.
> > 
> > I tried running the echo sample app on port 8081, and that gets this test 
> > passing, but a different test fails, because port 8081 is taked already.  
> > There must be a simple way to run the tests and have them pass, but what 
> > is it?
> 
> I had the same problem today with more than one test and found, that I
> had to repeat the tests multiple times and per test. They all work
> separately, it seems, but not together.

That's insane!  I need an XMLRPC library for a project that I am working 
on, and I would really like to use this one, but I am having a hard time 
trusting it currently.  I am going to start by going through and cleaning 
up all of the deprecated method calls.  Then I am going to put in support 
for the Collections framework instead of using Vector everywhere.

Ryan

Re: Running the tests

[Jochen Wiedmann <jo...@freenet.de>]

On Mi, 2004-06-16 at 15:08, Ryan Bloom wrote:

> For some reason, just running ant test is failing one test for me.  
> Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to 
> connect to a server.  I would have thought that "ant test" would have run 
> the server before trying to run the client, but that doesn't seem to be 
> the case for this test.
> 
> I tried running the echo sample app on port 8081, and that gets this test 
> passing, but a different test fails, because port 8081 is taked already.  
> There must be a simple way to run the tests and have them pass, but what 
> is it?

I had the same problem today with more than one test and found, that I
had to repeat the tests multiple times and per test. They all work
separately, it seems, but not together.


Jochen

Running the tests

[Ryan Bloom <rb...@redhat.com>]

For some reason, just running ant test is failing one test for me.  
Specifically, org.apache.xmlrpc.CommonsXmlRpcTransportTest, isn't able to 
connect to a server.  I would have thought that "ant test" would have run 
the server before trying to run the client, but that doesn't seem to be 
the case for this test.

I tried running the echo sample app on port 8081, and that gets this test 
passing, but a different test fails, because port 8081 is taked already.  
There must be a simple way to run the tests and have them pass, but what 
is it?

Ryan

Re: commons-codec version incompatiblity

[Jochen Wiedmann <jo...@freenet.de>]

On Di, 2004-06-15 at 19:01, Ryan Bloom wrote:

> So, I have one option (which kind of sucks), I can cast the byte[] to an 
> Object in the calls to encode/decode to retain compatibility between codec 
> 1.1 and 1.2.

Let it suck. :-) If you do that change, it will prevent a lot of hazzle
and questions in the future.


Jochen

Re: commons-codec version incompatiblity

[Daniel Rall <dl...@collab.net>]

Ryan Bloom wrote:
> I am trying to get xmlrpc building, and I am running into problems with 
> commons-codec 1.2.
> 
> Basically, the problem is in calling Base64.encode and .decode.  
> Essentially, the code 1.1 release had two encode and decode methods, one 
> that accepted a byte[] and the other accepted an Object.  In both cases, 
> Encoder/Decoder Exceptions were thrown if the argument wasn't a byte[].  
> In commons-codec 1.2, both methods still exist, but the one that accepts a 
> byte[] no longer throws the exception.
> 
> So, I have one option (which kind of sucks), I can cast the byte[] to an 
> Object in the calls to encode/decode to retain compatibility between codec 
> 1.1 and 1.2.

I've committed a patch based on Jochen's code to CVS HEAD.  It does not appear 
to need backporting to the 1.2 branch.