Issue #4550 XmlConfiguration argument matching

[gregw]

Improve #4550 argument matching by:

• rejecting obviously non matches (with allowance for unboxing)
• sorting methods so that derived arguments are tried before more generic (eg String before Object)

Signed-off-by: Greg Wilkins gregw@webtide.com

[gregw]

This change is to address the issue noticed by @joakime that:

the was using public boolean AbstractList.add(E e); not the one in Configurations.add(String ... configClassNames)

I think this is kind of a bad class design, but now at least we will deterministically favour a String over Object over String.... Note this doesn't fix the problem @joakime found. We would have to favour String... over Object to do that. Hmmm maybe we should ?

[gregw]

I have the order correct as the following test:

    private static class TestOrder
    {
        public void other(Object o)
        {
            System.err.println("object");
        }

        public void other(String... s)
        {
            System.err.println("string varargs");
        }
    }

    @Test
    public void testMethodOrdering() throws Exception
    {
        TestOrder to = new TestOrder();
        to.other("foo");
    }

prints object

[gregw]

Dang! still breaks things... stand by...

[sbordet]

Other than a nit in the comparator, LGTM.

[sbordet]

It's subtle that t1 and t2 are inverted here.
I would prefer Boolean.compare(!t1.isPrimitive(), !t2.isPrimitive()).

[gregw]

that's how I wrote it initially.... switching....