WebSphere, it’s a thing.

Spring, it’s another thing.

They generally play together nicely except for async. That’s a little harder. It’s especially harder when you can’t rely on EJB or the Spring-provided work manager, and your async methods aren’t actually spring-managed.

I have a spring-managed factory class, class ContextFactory that has a Context getInstance() method for newing up these stack-scoped objects. My Context class has a boolean commit() method that runs a series of async tasks. Because Context isn’t spring-managed, I can’t take advantage of AsyncResult or the Async annotation.

Solution: Inject my java.util.concurrency.ExecutorService into ContextFactory and expose a getExecutor so I can async manually from Context.

Problem: WebSphere explicitly requests that developers not use Spring’s async facilities directly, but instead load them from the WebSphere asynch beans work managers.

Well, after a few days of searching, here’s how:

<beans xmlns:jee="http://www.springframework.org/schema/jee"

<jee:jndi-lookup jndi-name="wm/default" id="taskExecutor"></jee:jndi-lookup>

<bean id="contextFactor" class="com.example.factory.ContextFactory">
	<constructor-arg index="0" ref="taskExecutor"/>

WebSphere provides a TaskExecutorWorkManager-compatible and ExecutorService-compatible bean at the default jndi of “wm/default”. You can create your own, and there’s some other stuff to do if you use Liberty profile, but I don’t know anything about that part.

Just a heads up, this doesn’t work on WebSphere 7.x, and the only other version I have to test (where it does) is WebSphere 8.5.5.