anonymous wrote : Figure 11-1 shows that the getWorkContexts() method is called by the WorkManager after the Work instance has been submitted by doWork(), startWork() and scheuleWork(). | | Chapter 10.3.3.5 states that a WorkCompletedException can be thrown with an appropriate error code which in this case is one of the WorkContextErrorCodes. Then, place that I put "setupWorkcontext" is wrong. I have to setup work contexts just before "Work" is run by the "WorkManager". In current codebase, it seems that there are several different methods that are responsible for setting up "ExecutionContext", namely "WorkManagerImpl#importWork" and "WorkManagerImpl#startWork". *Import* work is called by the "doWork()..." methods but *Start* work is called from "WorkWrapper#execute" method. But according to the spec., context has to be setup after *Work* is accepted and just before it is run. Then it seems that current implementation is wrong because context is imported before submitting work instance via "importWork" method. AFAIK from the specification, execution context is setup in "start" phase of the work lifecycle (submit->accept->start). And again according to the specification, if execution context is not setup succesfully within "start" phase, it throws "WorkCompletedException". But in WrapperImpl#execute method, it first calls "WorkManagerImpl#startWork" to do some execution context specific actions. If it gets exception it throws WorkRejectedException, otherwise it calls "run" method of the work instance. But spec says to throws WorkCompletedException. Sorry for pollution, but I do not exactly understand which methods in the codebase correspond to work's lifecycle phases "submitted, accepted, rejected, started and completed". Therefore, I do not know where to put "setupWorkContext" implementation. Morever, I guess that current execution context setups has to be changed also using new work context provider semantic. Effected places are "WorkManagerImpl#importWork,startWork, cancelWork,endWork" methods. anonymous wrote : There is a bit more work in regards to custom contexts if you see the last paragraph in 11.4.2 - the container must always check the most specific context first - and then go up the in hierarchy to find a supported one. | Specification says that this must done by the resource adapter before it submits work instance to the server via BootstrapContext#isContextSuported. I think that this is not related with the application server. Currently, I checked specific context support via method "WorkManagerImpl#getSupportedWorkContextClass(Class". This method checks given context class with application server supported context classes using ".equals". If it does not support specific instance, it falls through "super class" of the adaptor context class. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4243554#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...