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
Solution: Inject my
ContextFactory and expose a
getExecutor so I can async manually from
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" xsi:schemaLocation=" http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee.xsd"> <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"/> </bean> </beans>
WebSphere provides a
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.