Use CommonJ work manager support in Spring 2.0

Ross, what is this and is it still relevant?

CommonJ was an attempt by BEA and IBM for an API that allows container-managed apps to start threads, timers and such. Apparently there are several thread pool wrappers in Spring similar to our WorkManager facade, but if and how we can use them needs pretty close inspection. There is a JSR for "managed threading" as extension of the regular util.concurrent stuff which would then become the official CommonJ, but it is dormant since apparently nobody seems to think it's important enough to actually get the work done.

This is a low priority right now, since our work manager does the job we need and I ahven't actually used the CommonJ stuff

Also, at least one vendor (Tangosol) provides a distributed work manager, which transparently distributes the jobs across a cluster.

http://wiki.tangosol.com/display/COH32UG/Provide+a+Data+Grid#ProvideaDataGrid-WorkManager

you mean Orasol Yes they do and it's very cool. It would be possible now to plug that in by writing a custom ThreadingProfile (which acts as a factory for the workManager) We do something similar for the JCA adapter since we need to use the containers' WorkManager to comply with the spec.

The underlying assumption is that the Work item is serializable (note how the example conveniently ignores the creation of the item). That is quite often not the case or a good idea at all.
It's always good to check how the supercomputer folks feel about these supposedly novel approaches to "transparent distribution", especially considering that they abandoned these things a long time ago. Same with EJB.
In Mule's case we'd have to revamp a lot of the internal infrastructure again to make this work: neither connectors nor dispatchers are and likely never will be serializable.

Connectors and Dispatcher definitely not, but they don't necessarily constitute a work item since they are bound by a location. However, Services and composite service invocations could be farmed out into the grid.

All true, that was my point - in the end it's all very application-specific and needs to be explicitly managed/configured/accounted for from the beginning. My beef was not with the idea (though it opens a can of management problems) but rather with the overly simplistic example that looks just a bit too much like magic scalability pixie dust.
Besides everyone knows they just did that to annoy the javaspaces fans

I think this issue is no longer valid, since there is no need to use commonsJ and we can't depend on Spring for programmatic configuration