[rabbitmq-discuss] [Patch] .NET client: ignored params in QueueBind

Wed Jan 19 11:32:55 GMT 2011

On Wed, Jan 19, 2011 at 08:14:59AM +0000, Matthias Radestock wrote:
> Matthew Sackman wrote:
> >On Wed, Dec 29, 2010 at 11:30:48AM -0800, Vadim Chekan wrote:
> >>So either parameters must be checked for non-null constraint, or (my
> >>preference) null should be interpreted as empty parameter.
> >
> >Yeah, sadly there are many such cases in both the C# and Java clients of
> >this kinda thing. The one that annoys me the most is in the Java client
> >in queueDeclare - the queue name must be "" rather than null, but the
> >arguments map can be null. Grrrr.
> 
> There is a method to the madness...
> 
> The AMQP encoding of properties distinguishes between a null string
> and an absent string. While that distinction does not apply to AMQP
> method parameters, for consistency it might be desirable to apply
> the same principle there, and since all method parameters are
> mandatory a null value should not then be permitted. An NPE might
> not be the best way to complain about that though.

Right, and I'm not sure it's desirable to reflect such properties of the
binary codec in the Java API.

> >All of these need fixing - there are many such odd idiosyncratic aspects
> >to the Java and .Net clients
> 
> What other idiosyncratic aspects were you thinking of?

Oh things like arrays may not be used for arrays. They have to be lists.
See writeArray in ValueWriter. Somewhat annoying when you have to do
things like

    Map<String, Object> args = new HashMap<String, Object>();
    args.put("my-key", Arrays.asList(new String [] {"foo", "bar", "baz"}));
    String queueName =
            channel.queueDeclare("", true, true, false, args).getQueue();

Matthew