Skip to content

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

Closed
@spring-operator

Description

@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:

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions