Until Spring Integration 3 finally introduced built-in support for Jackson2, you are probably sticked at Jackson 1 (1.6 or so) for messaging serialization, i.e. used for AMQP endpoints like RabbitMQ. That was even more ugly in web projects where the complete MVC stack was Jackson2 ready, but not the integration part. Even though that situation is unattractive, you could always deal with without hacking converters because Jackson 1 and 2 have completely different namespaces (because of the migration back from codehaus to the fasterxml domain).
That changes now with Spring Integration 3.
My personal check list when migrating:
- Ensure no Jackson 1.x is in the classpath anymore. Yes, check it again. There are sometimes these little annoying transitive dependencies. If so, the automatic/magic resolver (aka legacy compatibility code) of Spring Integration will prefer it. You can handle this with custom transformers, but not the built-in directives.
- Forget the new introduced
MessageConverterin case of (AMQP) gateways, because it will not be used in the situation of message replies (INT-3285 which was actually a regression bug and will be fixed in 3.0.2).
- Know the existence of a Jackson’s
ObjectMapperwrapper. Yes, really. The
JsonObjectMappercan contain both Jackson1 and Jackson2 ObjectMappers.
- After point 3: If you want to customize the ObjectMapper (i.e. for a simple mapper.registerModule(new JodaModule());) you have to provide such a JsonObjectMapper. Easy with a small config.
- After point 4: Do not forget to add this custom ObjectMapper for each JSON transformer in use.
- An example
- Updated 15.02.2014
- adding reference to INT-3285
- Updated 03.05.2014
- INT-3285 resolved with release of Spring Integration 3.0.2