Revisit ConversionService strategy, since it is used in determining the mapping between Messages and Method parameters [INT-829]

[spring-operator]

Oleg Zhurakousky opened INT-829 and commented

Related to #4192
Current ArgumentArrayMessageMaper uses ConversionService.canConvert(..) method to determine the right mapping between Message attributes (e.g., payload or payload parameters, headers etc...) and method arguments.
Unfortunately current state of ConversionService contains quite a few generic Converters (e.g., Object to String etc...), which do not work well when trying to determine if Foo.class should or should not be mapped to a Payload of type String or header or even payload attribute (via EL expressions such as payload.fname). To accommodate this situation these generic converters are removed during ArgumentArrayMessageMaper initialization:

conversionService.removeConvertible(Object.class, Map.class);
conversionService.removeConvertible(Map.class, Object.class);
conversionService.removeConvertible(Object.class, String.class);

However, that creates a problem when determining if types such as Number and Date could be represented as Strings which results in registering two converters just for the purpose of checking if conversion could be completed

conversionService.addConverter(new Converter<Number, String>() {
		public String convert(Number source) {return null;}
		});
conversionService.addConverter(new Converter<Date, String>() {
		public String convert(Date source) {return null;}
		});

The actual conversion is not done by the ArgumentArrayMessageMaper but is done during the method invocation which in itself is a potential for improvement as described in the parent issue.

---

This issue is a sub-task of #4836

Issue Links:

• Enable registration of custom type converters [INT-174] #4192 Enable registration of custom type converters
  ("depends on")

[spring-operator]

Mark Fisher commented

The conversion is now managed within the SpEL expression evaluation, and since method resolution is also part of that evaluation, we no longer rely on these "external" calls to canConvert().

We will likely be providing a custom MethodResolver implementation so that we can filter the methods that are available. Otherwise, the current implementation does leave room for some ambiguities (when methods have the same name). See the comments in the parent issue for more detail.