DefaultMessageListenerContainer.setTaskExcecutor() binary compatibility broken [SPR-7468]

[spring-projects-issues]

Janet Moyer opened SPR-7468 and commented

Attempting to migrate from Spring 2.5.6 to 3.0.3.

During Spring initialization, we get this exception: java.lang.NoSuchMethodError: org/springframework/jms/listener/DefaultMessageListenerContainer.setTaskExecutor(Lorg/springframework/core/task/TaskExecutor;)

Spring 3.0's DefaultMessageListenerContainer.setTaskExecutor() parameter changed from org.springframework.core.task.TaskExecutor to java.util.concurrent.Executor.

When using setTaskExecutor to inject a bean of type org.springframework.scheduling.commonj.WorkManagerTaskExecutor, it fails because WorkManagerTaskExecutor doesn't implement Executor.

---

Affects: 3.0 GA

[spring-projects-issues]

Juergen Hoeller commented

Actually, WorkManagerTaskExecutor does implement Executor: indirectly through implementing the TaskExecutor interface which in turn extends Executor as of Spring 3.0.

I guess what you're seeing is a binary compatibility problem: You seem to call the setTaskExecutor method in your code somewhere (i.e. not in Spring property configuration where that problem wouldn't exist), and it looks like you need to recompile that code against the Spring 3.0.x jars before running it.

Juergen

[spring-projects-issues]

Chris Beams commented

Updated title to better reflect root issue.

Janet, if Juergen's comments don't apply, please re-open this issue and provide more information.

Otherwise, resolving as Won't Fix - certain binary incompatibilities in Spring 3.0 were by design; and as mentioned above, this is an issue that a) doesn't affect most because of the indirection through XML, and b) is easily solved by recompilation.