Running Camel Spring Batch component on JBoss Fuse 6.0

Solution Verified - Updated -


  • JBoss Fuse 6.0


When deploying Camel Batch component [1] into JBoss Fuse 6.0 you may encounter the following exception:

(MessageId: ID-WLDL6820-50289-1391183670967-2-1 on ExchangeId: ID-WLDL6820-50289-1391183670967-2-2). Exhausted after delivery attempt: 1 caught: java.lang.IllegalStateException:
 Could not deserialize object type
java.lang.IllegalStateException: Could not deserialize object type
    at org.springframework.batch.core.repository.dao.MapJobExecutionDao.copy(
    at org.springframework.batch.core.repository.dao.MapJobExecutionDao.saveJobExecution(
    at Source)[:1.7.0_45] Caused by: java.lang.ClassNotFoundException: org.springframework.batch.core.JobExecution
    at$ Source)[:1.7.0_45]
    at$ Source)[:1.7.0_45]

Unfortunately the version of the Camel Batch shipped with the JBoss Fuse 6.0 (2.1.9.RELESE) contains broken OSGi manifest. Due to the limitation of the manifest import statements the Spring Batch cannot deserialize executed jobs. The Spring Batch version shipped with the JBoss Fuse 6.1 (2.2.2.RELESE) is not affected by the mentioned OSGi manifest issue.



The simplest way to fix the import visibility issue in the Spring Batch is to enable dynamic-imports on the Spring Batch Core and Spring Batch Infrastructure bundles. This action can performed via the Fuse shell:

dev:dynamic-import SPRING_BATCH_CORE_BUNDLE_ID

You can retrieve the ids of these two bundles by executing the following command:

osgi:list | grep -i 'spring batch'

Dynamic imports, once enabled, are persisted and will affect the bundles even after the restart of the Fuse server.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.