users@glassfish.java.net

Using a WorkManager causes the thread execution context/classloader to change?

From: Alex Sherwin <alex.sherwin_at_acadiasoft.com>
Date: Thu, 13 Aug 2009 13:34:22 -0400

I've setup a WorkManager using the glassfish WorkManagerFactory class
(using the default thread pool). I'm attempting to use it to perform
asynchronous HTTP requests using the Jersey lib (along with apache
commons httpclient for basic/authentication purposes).

However, it appears as though when the WorkManager invokes the run()
method of the Work Object that the the execution context is different
then that of the application which scheduled the work. Jersey is
failing to find MessageBodyWriters and Readers, along with numerous
other issues associated with it... Is there any way to prevent this?

If I implement the same idea using ExecutorService with default
ThreadFactory, everything works as I would expect it to using the
WorkManager. However, I'd have to believe that running within the app
server it would be better to use the WorkManager to do this, so that it
utilizes threads from defined/configurable thread pools.

Is there something I'm doing wrong, or some other way of accomplishing this?