Enable registration of custom type converters [INT-174]

[spring-operator]

Mark Fisher opened INT-174 and commented

Currently, Spring's default type conversion applies to any POJO method registered as a MessageHandler (via annotations or XML). For example, conversion occurs automatically when passing a Message with a String payload of "12345" to a handler with: someMethod(int num)

Additional "default" converters should be added to the Spring Integration core for common transformation requirements, and it should be possible to register additional custom type converters. These converters will enable a majority of type-level Message Transformation to occur automatically without the need for explicit implementations of MessageTransformer.

---

Issue Links:

• Revisit ConversionService strategy, since it is used in determining the mapping between Messages and Method parameters [INT-829] #4838 Revisit ConversionService strategy, since it is used in determining the mapping between Messages and Method parameters
  ("is depended on by")
• Support type conversion for datatype channels [INT-912] #4918 Support type conversion for datatype channels

3 votes, 3 watchers

[spring-operator]

Mark Fisher commented

Deferring this since it is related to some ongoing discussion regarding access to application-wide context.

[spring-operator]

Mark Fisher commented

Moving to 2.0-M1 for now with the goal of creating some basic support for using the new conversion functionality of Spring 3. If it turns out to be a bigger task, we'll move it back to M2.

[spring-operator]

Mark Fisher commented

We'll add the converter support in M2. The EL support for message mapping has required a lot of refactoring in the same general code. I want to make sure we focus on that for M1. Adding the converters should be relatively simple (since the EL context supports converters already) after that work is completed.

[spring-operator]

Mark Fisher commented

A "conversionService" bean (of type ConversionService) will now be picked up and used for payload-type-conversion as necessary for any MessageChannels created with a "datatype" attribute in the <channel/> element (see #4918).

There are 2 other places where custom type-converters should apply (#1 for sure, #2 is questionable):

1. method-invoking adapters (POJO invocation for Transformer, Router, etc.)
2. a general payload-type converting Transformer implementation

For #2, we might consider something like the following:

<payload-type-transformer input-channel="in"
                          output-channel="out"
                          target-type="java.lang.String"
                          conversion-service="someConversionService"/>

The "conversion-service" attribute would be optional, but if not provided the transformer would require resolution of a "conversionService" bean within the context.

The reason that #2 may or may not be justified is that the <channel/> with "datatype" and the ConversionService-aware method-invoking adapters (where the "target-type" is determined by the targeted method parameter) handle most cases already. Nevertheless the transformer might still be useful since it allows for a more explicit, proactive declaration of intention.

Thoughts?

[spring-operator]

Mark Fisher commented

We need to decide how to pass the ConversionService to MethodInvokingMessageProcessor (since it's created at a pretty low-level and not current instantiated as a bean itself).

Also we need to decide on the bean name and potential fallback rules, e.g.

1. "integrationConversionService" bean
2. "conversionService" bean
3. ConversionServiceFactory.defaultConversionService()

Perhaps it does not make sense to consider option #2 at all, since that would be the ConversionService instance used for "bean-configuration", and any user-defined Converters provided there might not be relevant for Spring Integration scenarios.