Description
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")