Я решил использовать комбинацию решателей точек входа массива, решателей точек входа метода и изменения в сигнатуре API для решения этой проблемы. Проблема здесь в том, что Мул использует аргумент вызова веб-службы, чтобы определить, какой метод использовать вместо имени метода, даже если в его документации указано, что он использует кучу преобразователей, включая метод-entry-point-resolver.
Таким образом, если у вас есть интерфейс, который предоставляет два метода с разными именами, каждый из которых принимает один массив типа T, нет комбинации распознавателей, которая обеспечит вызов правильного метода. Не так далеко, как я мог сказать. Если вы укажете оба этих метода в коллекции method-entry-point-resolver следующим образом:
<method-entry-point-resolver>
<include-entry-point method="method1"/>
<include-entry-point method="method2"/>
</method-entry-point-resolver>
Мул всегда вызывает method1, если входным аргументом является T [], игнорируя имя метода.
Если вы попробуете это:
<method-entry-point-resolver>
<include-entry-point method="method1"/>
</method-entry-point-resolver>
<array-entry-point-resolver>
<include-entry-point method="method2"/>
</array-entry-point-resolver>
Мул все еще не вызывает правильный метод во все времена. В итоге я создал класс, который просто оборачивает T [] и изменил его в качестве входного аргумента на method1. Настроил method1 в наборе метода-точки-разрешения-точки входа, а метод2 в коллекции-точки-входа-точки-массива, и это работает.
Это, очевидно, проблема, но я не мог заставить парней MuleSoft ответить.