Skip to content

Spring Integration 6.3 to 6.4 Migration Guide

Jump to bottom
Artem Bilan edited this page Oct 4, 2024 · 3 revisions

Deprecate LobHandler usage

With modern drivers we don't need BLOB-specific handling anymore. The regular PreparedStatement.setBytes() and ResultSet.getBytes() are enough for our serialized messages. Therefore a LobHandler option of the JdbcChannelMessageStore, JdbcMessageStore, ChannelMessageStorePreparedStatementSetter and MessageRowMapper is deprecated with no replacement.

Improve JdbcLockRegistry and RedisLockRegistry

The unlock() operation of JdbcLockRegistry and RedisLockRegistry now throws a ConcurrentModificationException when the data in DB cannot be marked as unlocked properly. Also, the LockRepository.delete() now returns boolean result of unlocking query to notify a JdbcLockRegistry.JdbcLock.unlock() operation to throw a ConcurrentModificationException if delete has failed.

Control Bus Management

The SpEL and Groovy support for Control Bus EI pattern has been deprecated in favor of less invasive Control Bus Management via ControlBusCommandRegistry (and supplemental ControlBusController REST endpoint at /control-bus). The ControlBusCommandRegistry processes simple commands like beanName.methodName from message payload and uses IntegrationMessageHeaderAccessor.CONTROL_BUS_ARGUMENTS message header as a list of the arguments for method to call (if any). The bean and its method to call must fit into Control Bus requirements: marked with @ManagedResource or implement Lifecycle contract. In other words, the new functionality is similar to JMX API. The simple existing expressions like @myEdnpoint.stop() are still supported and converted internally into something like myEdnpoint.stop command, but those like @taskScheduler.setPoolSize(10) are not supported any more and have to migrate to more simple exposure, like taskScheduler.setPoolSize as a message payload and setHeader(IntegrationMessageHeaderAccessor.CONTROL_BUS_ARGUMENTS, List.of(10)). More complex expressions, like conditional, concatenations and based on method argument resolutions before target method call, have to migrate to dedicated service methods with simple signature to expose using @ManagedResource and @ManagedOperation/@ManagedAttribute.

Python Support to GraalVM Polyglot

The Python scripts support has been migrated away from Jython to GraalVM Polyglot, which support Python 3.x already (unlike Jython). So, the org.python:jython-standalone dependency has to be replaced now with org.graalvm.sdk:graal-sdk and org.graalvm.polyglot:python, respectively. For fast migration of existing applications without Python scripts modification, the PolyglotScriptExecutor has to be supplied with a Context.Builder and an option("python.EmulateJython", "true"). However, it is recommended to rely on the GraalPy interpreter for better performance altogether. Therefore imports for Java classes in Python scripts have to be migrated to the import java and it java.type() functions. For example, in our Cafe Scripted Sample we changed script from:

from org.springframework.integration.samples.cafe import Drink
import time

def prepareDrink(orderItem):
	print("python: preparing %s for order %s" % (orderItem,orderItem.order.number))
	time.sleep(eval(timeToPrepare))
	return Drink(orderItem.getOrder().getNumber(), orderItem.getDrinkType(), orderItem.isIced(),
              orderItem.getShots())
              
drink = prepareDrink(payload)

to

import time
import java

Drink = java.type("org.springframework.integration.samples.cafe.Drink")

def prepareDrink(orderItem):
	print("python: preparing %s for order %s" % (orderItem,orderItem.getOrder().getNumber()))
	time.sleep(eval(timeToPrepare))
	return Drink(orderItem.getOrder().getNumber(), orderItem.getDrinkType(), orderItem.isIced(),
              orderItem.getShots())
              
drink = prepareDrink(payload)

Pay attention to java.type() instead of Jython style from and orderItem object properties access via getters instead of properties references.

Clone this wiki locally